| 02:08 | <MikeSmith> | Domenic: re: "Gosh, wouldn't it be nice if HTML was something you could pull request..." dunno if you've seen https://github.com/w3c/spork#editing yet but that's exactly the intent of it |
| 02:08 | <MikeSmith> | it's pretty nuts really, on several levels |
| 02:08 | <MikeSmith> | from the twisted mind of Robin Berjon |
| 02:09 | <MikeSmith> | example of a spork PR for a bug fix to the spec https://github.com/w3c/spork/commit/d5fd2371fc7142eca2a70050e88879ff1f0e90ea |
| 02:10 | <MikeSmith> | not for the faint of heart |
| 02:24 | <Domenic> | Yeah I'd rather figure out a way to get changes into the spec used by implementers though, not the fork. |
| 02:41 | <TabAtkins> | MikeSmith: That's... pretty fucked. |
| 02:44 | <MikeSmith> | yeah I guess it's also not such a wonderful thing that right now the process of trying to get changes into this spec doesn't use the collaboration mechanisms we're now commonly using for most other specs |
| 07:50 | <annevk> | philipj: so remove hierarchy restrictions on requestFullscreen()... Then file a bug on HTML to define the inert thing based on top layer? Do we then still need top layer algorithms? Or should I define the inert stuff in Fullscreen? |
| 08:22 | <annevk> | jochen__: if you have time to chat about referrer today that'd be great |
| 08:33 | <annevk> | jochen__: I summarized all the points I want to talk about here: https://github.com/whatwg/fetch/issues/80 |
| 08:42 | <annevk> | mkwst: ^^ |
| 08:43 | <mkwst> | sorry, scribing a TAG meeting, arguing with them about security this afternoon. |
| 08:43 | <mkwst> | you should talk to jochen__ though! |
| 08:43 | <mkwst> | otherwise, I'm back home tomorrow. |
| 08:43 | <annevk> | alright, sounds good, I got a pile of stuff we need to go through :-P |
| 09:02 | <annevk> | JakeA: type "opaqueredirect"? |
| 09:05 | <JakeA> | annevk: works for me. Would it be more consistent to hyphenate? |
| 09:05 | <annevk> | JakeA: not necessarily, e.g. "sharedworker" |
| 09:07 | <JakeA> | annevk: true |
| 09:09 | <annevk> | Hmm, filtered responses don't filter url list |
| 09:09 | <annevk> | That seems like a bug |
| 09:10 | <annevk> | MikeSmith: I guess "basic filtered response" -> "basic filtered-response"? |
| 09:11 | <annevk> | MikeSmith: but "filtered response" can remain as is when it is on its own? |
| 09:28 | <philipj> | annevk: maybe an "add to top layer" algorithm isn't needed for the inert stuff, but perhaps for sanity if a spec tries to add an element which is already in the top layer? |
| 09:30 | <annevk> | philipj: you mean for the "add, or move if already present" phrase? |
| 09:30 | <MikeSmith> | annevk: well in that case it can stay as "basic filtered response" I think, because I think it's clear in context because there it's clear that "basic" is modifying "filtered response" (again, some of this comes down to judgement calls) |
| 09:51 | <smaug____> | impossible to get github.io working :/ |
| 09:52 | <philipj> | annevk: yes, exactly |
| 09:52 | <philipj> | unless HTML already says the very same thing and there is no problem |
| 10:02 | <annevk> | smaug____: what's the problem? |
| 10:02 | <annevk> | philipj: I'm happy to add add/remove abstractions while removing the hierarchical restrictions |
| 10:03 | <annevk> | philipj: I guess then someone needs to file a bug on HTML to do the remaining work around inertness |
| 10:03 | <philipj> | annevk: Sounds like a plan |
| 10:04 | <smaug____> | annevk: well, getting it to work, at least in Finland. for github folks http://smaug----.github.io/ seems to work, but not here in Finland. That page should have been there since last night already |
| 10:05 | <smaug____> | (I'd just like to expose serviceworkerconsole via some https pages) |
| 10:05 | <smaug____> | (similar silly little thing for testing as what http://mozilla.pettay.fi/workerconsole/ is) |
| 10:07 | <annevk> | Interesting, https://smaug----.github.io/ doesn't work |
| 10:07 | <annevk> | That's probably another case of Gecko's overzealous domain checker |
| 10:07 | <annevk> | smaug____: I get "Nothing to see" |
| 10:07 | <smaug____> | that is ok then |
| 10:07 | <smaug____> | Nothing to see is the expected |
| 10:07 | <annevk> | (in Gecko I get a certificate error) |
| 10:07 | <smaug____> | I get, "no server found" |
| 10:08 | <annevk> | (though only for the https version) |
| 10:09 | <smaug____> | so in theory https://smaug----.github.io/serviceworkerconsole/index.html might work. |
| 10:11 | <smaug____> | btw, I found serviceworker API overly complicated, and weird even for simple stuff like communication. One adds message listener to one object but uses postMessage on some other one. |
| 10:11 | <smaug____> | that is with about 15mins experience with SW API :) |
| 10:12 | <annevk> | smaug____: 404 in Chrome, cert error in Gecko |
| 10:12 | <smaug____> | fun |
| 10:12 | <smaug____> | oh well |
| 10:15 | <beverloo> | annevk, just to confirm, Notification.vibrate will expose the validated and normalized version of the pattern given in NotificationOptions, and will thus expose some of the UA-imposed limits (max length and max duration in the Vibration API) |
| 10:16 | <annevk> | yeah |
| 10:16 | <beverloo> | this is fine by me, but I don't want it to be an oversight :) |
| 10:16 | <beverloo> | as soon as FrozenArray is available in Chrome we'll ship it, hopefully Chrome 46 |
| 10:21 | <annevk> | cool |
| 10:27 | <MikeSmith> | annevk: fyi https://bugzilla.mozilla.org/show_bug.cgi?id=1184049 SteveF_ reports that for Notifications in Firefox, Firefox doesn't cause them to be exposed/announced to AT users in a way that makes them accessible |
| 10:28 | <annevk> | :-/ |
| 10:28 | <SteveF_> | marco found old bug he filed so moved over there https://bugzilla.mozilla.org/show_bug.cgi?id=1052776 |
| 10:28 | <MikeSmith> | ah ok |
| 10:30 | <MikeSmith> | btw I think another use case for having notification sounds is something Leonie mentioned, which is that if she has several channels open in an app like Slack or Gitter, and somebody pings her and it creates a notification, she doesn't know which channel it's from |
| 10:31 | <MikeSmith> | but I guess if things worked correctly she should be able to navigate automatically from that notification to whatever document/window that generated it |
| 10:32 | <MikeSmith> | focus on the notification, hit enter, it should focus the tab it came from |
| 10:32 | <MikeSmith> | ah yea but the problem is one tab/document can be showing several different chat rooms/channels at once |
| 10:34 | <MikeSmith> | man, I see Marco filed that bug more than year ago |
| 10:34 | <MikeSmith> | oh, not quite but almost a year ago |
| 10:36 | <annevk> | I believe i18n kind of sucks for notifications across implementations too :-/ |
| 10:36 | <MikeSmith> | yup |
| 10:37 | <MikeSmith> | things can only get better! |
| 10:38 | <annevk> | Yeah, but if you don't read windows-1252 or are blind or some such you're out of luck for the first five years of a new feature... |
| 10:39 | <annevk> | Have to hand it to Apple for getting those things right when they ship new products (at least that seems to be the general impression) |
| 10:42 | <Dumu> | Hello everyone, when I visit https://developers.whatwg.org with Firefox, it says it is in offline mode. But when I visit it with Chromium, it's fine. |
| 10:43 | <MikeSmith> | oh boy |
| 10:43 | <MikeSmith> | I wonder who decided it would be a good idea to use appache for that |
| 10:44 | <Dumu> | also ok with Opera |
| 10:45 | <MikeSmith> | Dumu: I'm not sure we still have an active maintainer for that version |
| 10:45 | <MikeSmith> | anybody remember who was maintaining it last? |
| 10:48 | <beverloo> | MikeSmith, annevk, fwiw, Sanghyun is looking at implementing the `sound` attribute for Chrome |
| 10:48 | <MikeSmith> | ah cool |
| 10:48 | <beverloo> | we're generally in favor, but figuring out reasonable limits will be interesting - don't want this to become a way of playing multi-minute audio tracks |
| 10:48 | <MikeSmith> | yup |
| 10:49 | <MikeSmith> | like window.name |
| 10:49 | <beverloo> | hah :) |
| 10:50 | <MikeSmith> | store you music collection in a notification.sound to share with others! |
| 10:50 | <MikeSmith> | Dumu: i'm still searching through logs to try to figure out who to ping about that doc |
| 10:50 | <annevk> | Dumu: developers.whatwg.org is not a recent version of HTML unfortunately |
| 10:50 | <beverloo> | before we supported Notification.data, developers were storing stuff in the hash part of the icon URL :/ |
| 10:51 | <MikeSmith> | hah |
| 10:51 | <Dumu> | I didn't realise it was an out-of-date version |
| 10:51 | <annevk> | MikeSmith: pretty sure it's https://twitter.com/benschwarz |
| 10:52 | <MikeSmith> | annevk: It was but I thought recently somebody else had been building it |
| 10:52 | <MikeSmith> | anyway you're right it's old |
| 10:52 | <annevk> | Dumu: https://html.spec.whatwg.org/multipage/ |
| 10:52 | <annevk> | I wish developers.whatwg.org listed a date somewhere |
| 10:53 | <MikeSmith> | Dumu: yeah you're best off just using the full https://html.spec.whatwg.org/multipage/ |
| 10:53 | <Dumu> | cool, thanks for letting me know - I shall disseminate this |
| 11:27 | <annevk> | smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1184059 if you care |
| 11:27 | <annevk> | smaug____: (about the cert error for your github.io thing which doesn't work in Finland anyway) |
| 11:28 | <annevk> | smaug____: can you access github.io through a VPN btw? Finland has a firewall of sorts? |
| 11:31 | <smaug____> | I can access https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html just fine |
| 11:31 | <smaug____> | annevk: interesting |
| 11:32 | <smaug____> | well, I can't access the http:// url either |
| 11:32 | <annevk> | smaug____: maybe your DNS provider is strict |
| 11:32 | <annevk> | smaug____: DNS resolver that is |
| 11:32 | <smaug____> | yup, could be |
| 11:32 | <annevk> | smaug____: perhaps if you use Google DNS or some such you could access it? |
| 11:32 | <smaug____> | not going to use google services |
| 11:32 | <smaug____> | but if there is something else |
| 11:32 | <annevk> | or OpenDNS |
| 11:33 | <annevk> | hmm |
| 11:35 | <smaug____> | hsivonen_: ping |
| 11:37 | <Ms2ger> | smaug____, on vacation, I think |
| 11:38 | <smaug____> | hmm, who else from Finland here... |
| 11:39 | <Ms2ger> | I guess poiru is in SF still |
| 11:40 | <smaug____> | it would be great it me trying to use github.io would reveal two bugs: one on operator side and one in Gecko |
| 11:40 | <smaug____> | s/it me/if me/ |
| 13:09 | <jochen__> | annevk: around? |
| 13:09 | <annevk> | jochen__: yup |
| 13:09 | <jochen__> | you wanted to chat |
| 13:10 | <annevk> | jochen__: yeah, did you see the new fetch issue I wrote up? |
| 13:10 | <jochen__> | yes |
| 13:10 | <jochen__> | makes sense i guess |
| 13:10 | <jochen__> | i still need to chat with jww about suborigins and pushState but that seems like a separate issue |
| 13:10 | <annevk> | jochen__: it has one open question at the end, how the global referrer policy interacts with request's referrer policy (aka referrer="") |
| 13:11 | <jochen__> | do we really need a referrer attribute on anchors? :-/ |
| 13:11 | <annevk> | jochen__: my understanding is that Yahoo! would like to set a global policy of "origin", but then use "unsafe-url" for some stuff they vetted in some way |
| 13:12 | <annevk> | jochen__: well, I'm not a big fan per se, but apparently some folks from Mozilla security are quite invested in it |
| 13:12 | <jochen__> | and by some you mean one |
| 13:12 | <jochen__> | and by invested you mean they implemented it and would rather not have their patch go wasted |
| 13:13 | <annevk> | well, I talked with at least three people the other day and they had invited more, but one of them has been doing the impl work I think |
| 13:13 | <jochen__> | in any case, i guess the only way this could work is that the referrer attribute just overrides the document's referrer policy when it creates a request |
| 13:14 | <jochen__> | i'd like to know what sid thinks of it |
| 13:14 | <jochen__> | he owns the core impl after all |
| 13:14 | <jochen__> | (in firefox) |
| 13:14 | <annevk> | right, it's not exactly hard, it just seems weird that an attribute could override a policy set through CSP |
| 13:14 | <jochen__> | yes |
| 13:14 | <jochen__> | but so does rel=noreferrer |
| 13:14 | <annevk> | well, that exposes less |
| 13:15 | <jochen__> | yeah |
| 13:15 | <annevk> | as I understand it the specific case Yahoo! is interested in is exposing more |
| 13:15 | <jochen__> | but you can also change the referrer policy to unsafe-url even though the csp said never |
| 13:15 | <jochen__> | (by inserting a fresh meta tag) |
| 13:15 | <annevk> | okay |
| 13:15 | <annevk> | so maybe referrer policy is a separate beast |
| 13:15 | <jochen__> | yes |
| 13:16 | <jochen__> | btw, we still lack feature detection |
| 13:16 | <jochen__> | that would actually be useful |
| 13:16 | <jochen__> | so sites wouldn't have to user-agent sniff |
| 13:16 | <annevk> | w("referrer" in document.createElement("a")) should work? |
| 13:16 | <jochen__> | but I don't know how to expose this in the platform |
| 13:16 | <jochen__> | when we have the referrer attribute, that's right |
| 13:17 | <jochen__> | it still doesn't tell you which policies the browser supports |
| 13:17 | <jochen__> | e.g. safari still only has the policies that adam and me defined in the whatwg wiki |
| 13:17 | <annevk> | jochen__: if you make the referrer attribute reflect known values, you could inspect it by setting a policy and then seeing if the user agent kept it or returns the default value |
| 13:17 | <annevk> | jochen__: that's the normal way it works for HTML attributes |
| 13:18 | <jochen__> | ok |
| 13:18 | <jochen__> | at least the attribute would be a bit more useful then |
| 13:19 | <annevk> | jochen__: https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-known-values |
| 13:20 | <annevk> | jochen__: for fetch() we could also support both... |
| 13:21 | <annevk> | jochen__: fetch(url, {referrer:"/yay", referrerPolicy:"origin"}) |
| 13:21 | <jochen__> | hum |
| 13:22 | <jochen__> | can we use something like referrerPath or something? |
| 13:22 | <jochen__> | if a.referrer is a policy, using referrer for the path in fetch is odd |
| 13:22 | <annevk> | I think that boat has sailed :/ |
| 13:22 | <jochen__> | hurray for consistency |
| 13:23 | <annevk> | Request.prototype.referrer is a thing |
| 13:23 | <annevk> | We could still rename the attribute though, that hasn't shipped |
| 13:23 | <jochen__> | and I guess that's a full url, right? |
| 13:23 | <annevk> | yes |
| 13:23 | <jochen__> | yeah, then let's name the anchor thing referrerPolicy |
| 13:25 | <annevk> | okay, I'll try to write up all the bits in Fetch |
| 13:26 | <jochen__> | thx |
| 13:32 | <annevk> | philipj: I'll take another look at Fullscreen tomorrow |
| 13:36 | <annevk> | Hmm, Fetch is >4000 lines. Oh, DOM is >9000 lines. |
| 13:37 | <annevk> | Heh, HTML is >85000 lines |
| 13:37 | <philipj> | annevk: thanks, nothing urgent, just went through the open bugs to see if there was anything interesting |
| 13:40 | <wanderview> | annevk: do we have the proposal anywhere for storage boxes to do their own LRU? not in the spec and the old wiki page just directs to here: https://storage.spec.whatwg.org/ |
| 13:40 | <wanderview> | or just the concept of temporary |
| 13:41 | <annevk> | wanderview: https://wiki.whatwg.org/wiki/Storage#Cache_boxes |
| 13:41 | <annevk> | wanderview: the wiki page is marked obsolete, but still contains all the old info |
| 13:41 | <wanderview> | hmm... it didn't seem to show any of it to me |
| 13:42 | <annevk> | works in private mode too |
| 13:44 | <wanderview> | ok, I see the content there now |
| 13:44 | <wanderview> | I must just still be asleep |
| 14:02 | <wanderview> | annevk: can a redirect have an anchor ref on it? |
| 14:02 | <wanderview> | does that make sense? |
| 14:12 | <annevk> | wanderview: yes it can |
| 14:12 | <JakeA> | wanderview: step 19 suggest it can https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents |
| 14:12 | <JakeA> | Damnit, I'm always slower than annevk |
| 14:13 | <annevk> | well, your answer was more useful |
| 14:13 | <JakeA> | I'll take that as today's 'win' |
| 14:13 | JakeA | goes to bed |
| 14:14 | <annevk> | JakeA: fixed the redirect thing, though found some new issues to sort through with request's client and such... |
| 14:15 | <JakeA> | annevk: what are the issues? |
| 14:15 | <annevk> | JakeA: for client requests, request's client is null, but that is wrong as the request still needs to be added to some fetch registry |
| 14:16 | <wanderview> | annevk: can you confirm the only way Response.url can be set is via the fetch() function? |
| 14:16 | <annevk> | JakeA: and apparently Gecko tracks two "clients", a trigger and loading client |
| 14:16 | <annevk> | JakeA: haven't quite worked through how that is significant yet |
| 14:17 | <annevk> | wanderview: I'm not sure what that means |
| 14:17 | <annevk> | wanderview: I gotta go for a bit, back in an hour or so |
| 14:17 | <JakeA> | annevk: possibly for requests that may not create a client? |
| 14:17 | <JakeA> | wanderview: yeah, I believe that's the case. Manually created responses have an empty url |
| 14:18 | <wanderview> | JakeA: annevk: and Response.redirect() just sets the Location header... not the url |
| 14:18 | <JakeA> | Correct |
| 14:18 | <wanderview> | ok |
| 14:18 | <wanderview> | trying to help a contributor fix our Response.url getter to strip the anchor fragment |
| 14:18 | <wanderview> | thanks |
| 14:39 | <smaug____> | annevk: ok, atm looks like the github.io is a linux issue o_O |
| 14:40 | <smaug____> | I can access the address on non-linux systems |
| 14:40 | <smaug____> | this is fun |
| 14:51 | <annevk> | smaug____: URLs are lots of fun |
| 15:14 | <annevk> | wanderview: Response.redirect() is a shorthand for a synthetic response |
| 15:40 | <MikeSmith> | does Opera 12 have something built in that causes it to automatically send validation validation requests to the W3C validator? |
| 15:41 | <MikeSmith> | the #1 user agent I see by far in the validator logs is Opera/9.80 (Windows NT 6.2; Win64; x64) Presto/2.12.388 Version/12.16 |
| 15:41 | <annevk> | Domenic: the main thing that's holding me back from adding promises to places is actually deciding between rejection and fulfilling |
| 15:42 | <Ms2ger> | MikeSmith, I remember it having something like that |
| 15:42 | <Ms2ger> | MikeSmith, or semi-automatically |
| 15:42 | <annevk> | Domenic: that is, Notification.requestPermission() and requestFullscreen()/exitFullscreen() |
| 15:42 | <annevk> | philipj: ^^ |
| 15:42 | <MikeSmith> | Ms2ger: ok that would explain it then I guess |
| 15:44 | <MikeSmith> | it seems to account for 13.5% of all the requests the validator receives |
| 15:48 | <caitp> | that's strange given the market share can't be more than a sliver |
| 15:49 | <annevk> | Yeah, that seems unlikely... There's right-click to validate option iirc, but accounting for 13.5%... Perhaps a bot? |
| 15:50 | <Ms2ger> | Especially with nobody using Opera anymore |
| 15:54 | <MikeSmith> | well there's a weird pattern to the referres |
| 15:54 | <MikeSmith> | *referrers |
| 15:54 | <MikeSmith> | they're all things like this: |
| 15:54 | <MikeSmith> | http://webtsf.bidbuy.co.kr/translation/?bbOpt=100011&bbUrl=http://validator.w3.org/check?uri=http%3A%2F%2Fvgn.vn%2Fflash%2Fprofile%2Falizaschurr |
| 15:55 | <MikeSmith> | e.g., some URL with the validator URL as a query param |
| 15:56 | <MikeSmith> | but randome other than that |
| 15:57 | <annevk> | perhaps it's some Russian bot network using Opera? |
| 15:57 | <MikeSmith> | I mean there's otherwise no pattern to the URL of the referring site not to the value of the "uri" param in the part that's a URL for the validator |
| 15:57 | <MikeSmith> | yeah seems like |
| 15:57 | <annevk> | maybe that's why Opera is popular in Russia |
| 15:57 | <MikeSmith> | gotta be something like that |
| 15:57 | <annevk> | :-P |
| 15:57 | <MikeSmith> | heh |
| 15:58 | <Domenic> | annevk: right, yeah. For methods named request I can go either way. I guess we have some minor precedent for rejecting with some of the newer permission-requesters. |
| 15:58 | <annevk> | Hmm, I really dislike throwing methods |
| 15:58 | <annevk> | Well, unless it's truly exceptional, but permissions don't feel like that |
| 16:02 | <TabAtkins> | I used to hate throwing methods, but working with more Python made me tolerate them more. |
| 16:02 | <philipj> | annevk, Domenic, with Notification.requestPermission(), are we talking about requesting fullscreen permission up-front? |
| 16:03 | <philipj> | MikeSmith: I think some version of Opera desktop had a "validate" thing in the context menu actually |
| 16:03 | <Domenic> | philipj: you mean for requestFullscreen? |
| 16:03 | <philipj> | MikeSmith: confirmed, Opera 12.16 has this (terrible idea, right?) |
| 16:04 | <philipj> | Domenic: well, I'm trying to understand what annevk wanted me to comment on above :) |
| 16:05 | <annevk> | philipj: Notificaiton.requestPermission() is another API we want to return a promise for |
| 16:05 | <annevk> | philipj: and it's not clear what the reject/fulfill tradeoff is |
| 16:06 | <Domenic> | Let's be sure I'm remembering the precedent right. |
| 16:06 | <philipj> | annevk: oh, I thought you were talking about difficulties with having requestFullscreen() return a promise |
| 16:06 | <Domenic> | Well, permissions API .request() is totally unspecified, so that's no help... |
| 16:07 | <philipj> | What is the tradeoff anyway? Whether or not to let scripts know that they don't have permission? o_O |
| 16:07 | <Domenic> | no, whether to say true/false for permission, or to fulfill/reject |
| 16:08 | <Domenic> | s/say/fulfill with/ |
| 16:08 | <Domenic> | basically, is it exceptional to be denied permission when requesting it |
| 16:08 | <philipj> | oh, I see |
| 16:08 | <philipj> | Promise<boolean> that always fulfils vs. Promise<void> that can be rejected? |
| 16:08 | <Domenic> | yep |
| 16:09 | <philipj> | I see. Considering code like requestPermission("foo").then(function() { doIt(); }) it seems less error-prone to reject |
| 16:09 | <Domenic> | yeah but consider code like `await requestPermission("foo")` |
| 16:10 | <Domenic> | Should it be `if (await requestPermission("foo")) { doIt(); } else { dontDoIt(); }` |
| 16:10 | <Domenic> | or should it be `var ok = false; try { requestPermission("foo"); ok = true; } catch (e) { dontDoIt(); } if (ok) { doIt(); }` |
| 16:11 | <Domenic> | the latter being worst-case I guess; if it's truly exceptional you would let it bubble and handle it at a higher level. |
| 16:11 | <philipj> | I hadn't even seen the syntax for await until now, so I'm afraid I'm of no use here |
| 16:11 | <Domenic> | the latter line should be `try { await requestPermission("foo"); ...` |
| 16:12 | <philipj> | so when using await, a rejected promise will throw an exception, right? |
| 16:12 | philipj | reads http://jakearchibald.com/2014/es7-async-functions/ |
| 16:14 | <Domenic> | Yep |
| 16:14 | <Domenic> | I am coming around to bool |
| 16:14 | <Domenic> | (Or PermissionStatus) |
| 16:15 | <philipj> | Don't know about Notification.requestPermission(), but in the case of requestFullscreen() I think it would be pretty odd to not reject in the case where we currently fire fullscreenerror |
| 16:18 | <Domenic> | Agreed, those are true error cases though right? Not just denial. |
| 16:19 | <philipj> | Right, at this point they're cases where the API has been used incorrectly |
| 16:19 | <Domenic> | +1 |
| 16:19 | <Domenic> | OK, I entered all this reasoning into https://github.com/w3c/permissions/issues/41 |
| 16:19 | <philipj> | There was a time when people wanted to ask for permission before entering fullscreen, in a kind of two-step model, but that time has passed |
| 16:19 | <Domenic> | Hopefully nobody will disagree strongly. |
| 16:19 | <philipj> | Just use many words and everyone will agree. |
| 16:47 | <annevk> | philipj: so fulfill with undefined, reject with TypeError? |
| 16:48 | <philipj> | annevk: maybe fulfil with the element that is now fullscreen, or would that be un-idiomatic? |
| 16:48 | <philipj> | I guess you could look at document.fullscreenElement |
| 16:48 | <annevk> | yeah, it's also the element you just invoked the method on |
| 16:49 | <philipj> | so fulfil with undefined seems OK, if there's strong guarantee that document.fullscreenElement inside the promise callback will be the element that you requested fullscreen on |
| 16:50 | <philipj> | I'm not sure it will be in weird cases where you request fullscreen on two elements at once, though? |
| 16:50 | <annevk> | I guess, or if you invoke requestFullscreen from the event? |
| 16:53 | <philipj> | but then, you can still know which event you requested fullscreen on, so also passing it to the callback might confuse people about why this is so |
| 16:54 | <philipj> | so let's not |
| 16:54 | <philipj> | as for rejection, as TypeError the typical thing? |
| 16:54 | <philipj> | s/as/is/? |
| 16:55 | <Ms2ger> | I believe so |
| 16:56 | <philipj> | If so that WFM, annevk |
| 16:57 | <annevk> | I TypeError all the things :-) |
| 16:57 | <annevk> | It's the new DOMException |
| 16:57 | <Domenic> | Hmm https://w3c.github.io/push-api/#widl-PushManager-subscribe-Promise-PushSubscription--PushSubscriptionOptions-options rejects with PermissionDeniedError for not-granted. |
| 16:58 | <Domenic> | annevk: isn't it fulfill with true? Or fulfill with false if permission is denied? |
| 16:58 | <annevk> | Domenic: not if we're going to reject for fullscreenerror events |
| 16:58 | <Domenic> | Right I guess fullscreen is a weird one here. |
| 16:58 | <philipj> | If permission is denied you exit fullscreen again |
| 16:59 | <Domenic> | yeah |
| 16:59 | <Domenic> | it's barely asynchronous, really... just a turn or two of the event loop for rendering stuff to happen. |
| 16:59 | <philipj> | annevk: I've noticed you like TypeError a lot, is there some consensus that it's the new black, or are other editors going on other types? |
| 16:59 | <annevk> | always fulfill with PermissionStatus makes sense for Notification I think |
| 17:00 | <philipj> | Domenic: well, that and actually doing the resize on the browser side |
| 17:00 | <annevk> | philipj: not sure, I'm mostly trying to be more compatible with non-browser JavaScript |
| 17:00 | <annevk> | philipj: and Allen has this philosophy that branching on exceptions isn't really done in JavaScript, which seems mostly true |
| 17:01 | <philipj> | annevk: right, so the choices are EvalError, RangeError, ReferenceError, TypeError and URIError? |
| 17:01 | <annevk> | philipj: mostly Range and Type |
| 17:01 | <philipj> | RangeError for things like index out of bounds? |
| 17:02 | <annevk> | philipj: yeah |
| 17:02 | <philipj> | btw, is it possible use just Error? |
| 17:02 | <philipj> | for things that just don't have anything to do with types? |
| 17:02 | <annevk> | philipj: I guess, not sure if JavaScript does that anywhere |
| 17:02 | <philipj> | oh well, I won't interfere with that, just curious :) |
| 17:04 | <annevk> | philipj: the other thought is uplifting features to be JavaScript builtin libraries |
| 17:04 | <annevk> | philipj: doesn't apply much to Fullscreen and Notifications I guess, but would e.g. for URL |
| 17:06 | <philipj> | Well... it'd be hard to ensure consistent internal and web-facing behavior for URLs then, but sure, there are definitely some bits that may eventually be in JS. |
| 17:37 | <annevk> | Microsoft's Web Component strategy is surprisingly similar to that of Mozilla |
| 17:39 | <annevk> | philipj: perhaps we should fulfill with true if something changed and false if nothing changed? |
| 17:40 | <annevk> | philipj: was just reading your comment in Bugzilla |
| 17:59 | <smaug____> | annevk: they sent some new information ? |
| 17:59 | <smaug____> | MS |
| 18:01 | <annevk> | waiting for bit.ly and to.co... |
| 18:01 | <annevk> | smaug____: they wrote http://blogs.windows.com/msedgedev/2015/07/15/microsoft-edge-and-web-components/ |
| 18:01 | <annevk> | smaug____: doesn't say much |
| 18:05 | <wanderview> | annevk: they at least gave a rough ordering of features they woudl implement |
| 18:06 | <wanderview> | template, shadow dom, custom element |
| 18:06 | <annevk> | yeah, that's also roughly the order of stable to unclear |
| 18:07 | <annevk> | I wonder if anyone has any tricks up their sleeve for custom elements |
| 18:08 | <annevk> | Other than making a decision that we hope JavaScript won't restrict private state to constructors and run with it... |
| 18:14 | <Domenic> | I have a trick I've been working on... |
| 18:14 | <Domenic> | It's still about three-quarters baked, so I haven't sent it anywhere, but you can poke around my GitHub... |
| 18:15 | <annevk> | Heh |
| 18:15 | <Domenic> | "we in FirefoxOS no longer are working on creating a "web apps" platform" ???? from https://groups.google.com/forum/#!topic/mozilla.dev.platform/RAHBNdesiXs |
| 18:15 | <annevk> | I'll have a look, was afraid that meeting was going to be sad |
| 18:15 | <tantek> | wat |
| 18:16 | <annevk> | Domenic: Mozilla co-opted "web apps" at some point to mean iOS/Android-style apps with web technology, iirc |
| 18:16 | <Domenic> | oh... that makes more sense... |
| 18:16 | <annevk> | Domenic: i.e., packages |
| 18:18 | <annevk> | Though I think also Firefox OS shifted thinking somewhat from being about applications to just being about the web, but I haven't really seen any demos |
| 18:18 | <tantek> | annvevk I'm starting to think that the whole "JSON side-file" approach is a giant anti-pattern as all it does it provide another vulnerable surface for JSONLDists to attack. |
| 18:18 | <Domenic> | hahahahahaha |
| 18:19 | <annevk> | tantek: that thread really could use some JSON-LD trolling... |
| 18:19 | <tantek> | Doesn't "app" just mean "something that requires more work for the user to find, install, update, because apparently users prefer to futz with re-arranging icons on a homescreen more than actually do anything useful" ? |
| 18:20 | <annevk> | Yeah, it's not clear that "apps" are actually a great thing for the web to try to emulate |
| 18:21 | <annevk> | This whole game of playing to the strengths of native is getting old |
| 18:21 | <tantek> | yup |
| 18:22 | <wanderview> | annevk: my understanding is the current plan is for fxos "apps" to just be SW-enabled pages... dangerous APIs will require the content to be in a signed package, though |
| 18:22 | <tantek> | for some reasons "native" popularized "install" as more sexy than "bookmark" even though they're basically the same thing (modulo pre-caching etc.) |
| 18:23 | <annevk> | tantek: yes, that has been my party-line for years, and yet folks still insist on "install" being a separate thing, as e.g. happens in that thread |
| 18:23 | <tantek> | also 2D views of "installed" icons, vs. 1D lists of "bookmarked" text titles and URLs |
| 18:23 | <tantek> | annevk, cheers. |
| 18:24 | <annevk> | tantek: https://the-pastry-box-project.net/anne-van-kesteren/2013-december-2 |
| 18:25 | <tantek> | annvek, but wait, it's not enough to be able to "bookmark" AND "install", we need to be able to "pin" all the things too! |
| 18:25 | <annevk> | I'm not sure it's good or bad that I haven't adjusted my vision much since Dec 2013 |
| 18:25 | <tantek> | annevk: that's what you get for being "visionary" |
| 18:26 | <Domenic> | i don't think the term matters. install is most familiar to users. bookmark connotes things that only work online. |
| 18:26 | <tantek> | HAHAHAHAHA |
| 18:26 | <Domenic> | and yes, i know that back in the day firefox's offline mode used to be awesome |
| 18:26 | <tantek> | most (90%+?) of the "native" apps I've seen installed only work online |
| 18:27 | <Domenic> | but these days everybody says no-cache on their homepage |
| 18:27 | <annevk> | iOS uses "[GET]", not install |
| 18:27 | <tantek> | annevk - true, I think that changed in iOS7 (from [Install] to [Get] in the Apple App Store) |
| 18:27 | <Domenic> | native apps "work" offline, in that they display branded error pages saying "this app needs internet for reason X" instead of "DNS_NETWORK_ERR_NOT_CONNECTED" |
| 18:28 | <tantek> | hahaha awesome |
| 18:28 | <Domenic> | that's a big difference |
| 18:28 | <annevk> | I think that's actually a valid point |
| 18:28 | <annevk> | And I think I might use a service worker for site just for that |
| 18:28 | <tantek> | Domenic: we need a gallery of all those branded error pages with a caption - "How's your native offline support doing now?" |
| 18:28 | <annevk> | Offline branding |
| 18:28 | <Domenic> | annevk: yep, +1 |
| 18:28 | <tantek> | sounds like a posterframe |
| 18:29 | <Domenic> | annevk: was vaguely thinking manifest/splash screen stuff could maybe help with auto-generation of such pages, but SW will of course give the most power. |
| 18:29 | <Domenic> | annevk: also https://github.com/whatwg/resources.whatwg.org/issues/7 and https://github.com/whatwg/resources.whatwg.org/issues/6 :) |
| 18:44 | <TabAtkins> | annevk: Any chance you could define "sibling list" of an object in DOM? Would be the object and all of its siblings. |
| 18:44 | <TabAtkins> | bz is asking me to clarify what Selectors means when :nth-child() talks about siblings, for elements without a parent. |
| 19:34 | <annevk> | TabAtkins: you can't have siblings without a parent |
| 19:36 | <Tshot> | Hi guys, anyone in here? |
| 19:43 | <TabAtkins> | annevk: Exactly. But you are the sole element in your sibling list in that case. |
| 19:43 | <TabAtkins> | You don't have any *other* siblings. |
| 19:45 | <annevk> | TabAtkins: it sounds like you want something like siblings or self |
| 19:45 | <Domenic> | specifiction really feels like the new public-html |
| 19:46 | <m2n> | Hello, Can somebody suggest me how can I include multiple values in a header in the single request. like setRequestHeader("%d = %d",a,b) ? So, basically I want to set the custom header here ? |
| 19:46 | <TabAtkins> | Domenic: That's the definition of "open to the public, and browser vendors don't pay much attention", yes. |
| 19:46 | <Domenic> | a shame, it's so much more readable on mobile |
| 19:47 | <TabAtkins> | annevk: Yes, that's what I want. Well, siblings *and* self. The data structure that :nth-child() et al operate on. |
| 19:47 | <Domenic> | maybe someone could pay ForbesLindesay to revamp readable-email.org. It was a good start but needs more love. |
| 19:47 | <TabAtkins> | Without a parent, you're the only element in your sibling list, so you match :first-child and :last-child. |
| 19:48 | <annevk> | TabAtkins: note that nothing in https://dom.spec.whatwg.org/#trees uses "list" |
| 19:48 | <Domenic> | TabAtkins: nothing in https://github.com/tabatkins/bikeshed/blob/master/docs/infotree.md for comments? |
| 19:48 | <TabAtkins> | annevk: Sure, is that relevant? |
| 19:49 | <TabAtkins> | Domenic: Not yet, but I'm happy to add if you want them. What format? |
| 19:49 | <Domenic> | TabAtkins: I was thinking # for until-end-of-line |
| 19:49 | <annevk> | TabAtkins: I'd prefer some term that matches the existing set |
| 19:49 | <TabAtkins> | Domenic: Yeah, that's my first impulse as well. |
| 19:49 | <annevk> | TabAtkins: ah, inclusive sibling is prolly it |
| 19:49 | <TabAtkins> | Gimme a bit to finish what I'm working on and I'll implement. |
| 19:49 | <annevk> | TabAtkins: file an issue? |
| 19:50 | <Domenic> | TabAtkins: although I found "personal" as a group so I no longer need `Group: WHATWG # I like their CSS better` |
| 19:50 | <TabAtkins> | Domenic: ??? |
| 19:50 | <Domenic> | TabAtkins: I am doing a personal spec and got momentarily stuck on what group to put |
| 19:50 | <TabAtkins> | Oh. I... was going to remove personal, as it's really "Tab's personal specs". |
| 19:50 | <Domenic> | My first instinct was WHATWG with a comment saying "this is actually just a personal spec" |
| 19:51 | <Domenic> | oh lol |
| 19:51 | <TabAtkins> | But wtv |
| 19:51 | <TabAtkins> | Like, it includes some things that are specific to the dir structure of my github. ^_^ |
| 19:51 | <Domenic> | haha ok well we'll see how this goes |
| 19:51 | <TabAtkins> | I guess that's just Prism, from before I added syntax highlighting to Bikeshed at all. |
| 19:52 | <TabAtkins> | Domenic: You can just omit the Group, you know. |
| 19:52 | <Domenic> | TabAtkins: that gives csswg I'm told |
| 19:52 | <TabAtkins> | Domenic: No? I mean, it uses the same stylesheet. |
| 19:53 | <Domenic> | Group must contain the name of the group the spec is being generated for. This is used by the boilerplate generation to select the correct file. It defaults to "csswg". |
| 19:53 | <Domenic> | from https://github.com/tabatkins/bikeshed/blob/master/docs/metadata.md |
| 19:53 | <TabAtkins> | Oh, I need to update that documention, sorry. |
| 19:53 | <Domenic> | oh cool |
| 19:54 | <TabAtkins> | Omitted group is explicitly no group. It uses the standard CSSWG styling, but it has a CC0 copyright license by default and doesn't do anything weird about SotD or anything. |
| 19:56 | <Domenic> | sounds perfect |