| 00:29 | <GPHemsley> | annevk: Sure, I'll take a look |
| 00:51 | <GPHemsley> | annevk, Domenic: For reasons unknown, there is no way to change a user's e-mail address without editing the database directly. |
| 00:51 | <GPHemsley> | annevk, Domenic: I have done so, and sent a new password reset e-mail. |
| 00:51 | <GPHemsley> | annevk, Domenic: If this turns out to be a bogus request, though, it's on you. ;) |
| 01:00 | <Domenic> | GPHemsley: thanks! All sorted. |
| 01:01 | <GPHemsley> | cool |
| 06:37 | <JonathanNeal> | This was an excellent discussion. https://bugzilla.mozilla.org/show_bug.cgi?id=946370 |
| 06:40 | <JonathanNeal> | https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#screenreader this addresses my need to identify content for screenreaders. |
| 08:27 | <annevk> | Hmm, I guess I should start writing a wiki page for Shadow DOM too with a summary of all those emails |
| 08:27 | <annevk> | 75 emails |
| 08:29 | <othermaciej> | I should read them all and say something constructive instead of just snarking |
| 08:36 | <annevk> | My main takeaway is that event retargeting is contentious |
| 08:36 | <annevk> | Encapsulation is still a problem |
| 08:37 | <annevk> | And per rniwa I get the impression that there are some aspects of the current design that prevent isolation |
| 08:38 | <annevk> | I've unfortunately poorly kept track of Shadow DOM discussion to date so I would have to do some digging |
| 08:38 | <annevk> | I guess I might start doing that soonish |
| 08:42 | <othermaciej> | the current design doesn’t have isolation |
| 08:43 | <othermaciej> | I don’t think it would be that hard to add |
| 08:43 | <othermaciej> | making it the default (as I think it should be) would probably require a compat break with what what shipped in Chrome |
| 08:44 | <annevk> | othermaciej: actual isolation requires something worker-like though, no? |
| 08:44 | <othermaciej> | oh, really real isolation? |
| 08:44 | <othermaciej> | not really |
| 08:44 | <othermaciej> | I am not sure why people suggest that at all |
| 08:44 | <annevk> | The +1 button? |
| 08:44 | <othermaciej> | the actual UA doesn’t use workers to implement built-in elements |
| 08:45 | <othermaciej> | there’s no need to have a separate thread of control |
| 08:45 | <annevk> | Well yeah I don't mean workers per se, I just mean that the globals can't reach each other |
| 08:45 | <othermaciej> | you just need a two-way membrane and separate global objects |
| 08:45 | <annevk> | Workers have that the best, the <iframe> setup is rather special |
| 08:45 | <othermaciej> | assuming you want to protect the component from the page |
| 08:46 | <annevk> | So Gecko has a really cool membrane setup as I understand it, but nobody else is interested in adopting it |
| 08:46 | <othermaciej> | basically the way the page could attack the component is by pre-hacking the JS global environment (for example modifying methods on prototypes), or by passing it poison values |
| 08:46 | <othermaciej> | you can solve the first by giving a component (or maybe set of components loaded from a given origin) its own global object |
| 08:47 | <annevk> | So in your estimation we just need to tweak the existing shadow DOM a bit? |
| 08:47 | <othermaciej> | and the second either by using very crude message passing, or by making method/property access do an extended version of the structured clone algorithm at the boundaries |
| 08:47 | <othermaciej> | it’s been a while since I looked into the details of what it would take to provide just the DOM level of encapsulation |
| 08:47 | <othermaciej> | but once you have that, you need a way to instantiate components from a separate global |
| 08:48 | <othermaciej> | I don’t think Shadow DOM quite has that in scope |
| 08:48 | <othermaciej> | I always imagined some form of cross-domain safe thing like HTML imports where you can also import custom elements from it |
| 08:48 | <othermaciej> | and those custom elements have all their JS run in a separate global object with the membrane thing |
| 08:48 | <annevk> | Okay so yeah, you're looking at something quite different then compared to what is there now |
| 08:48 | <othermaciej> | Adam Barth sort of agreed a while ago that this basic plan could lead to the possibility of sound two-way isolation |
| 08:49 | <othermaciej> | I think the shadow DOM piece is mostly right (except for its failure to do DOM encapsulation) |
| 08:49 | <othermaciej> | doing script isolation requires a separate mechanism |
| 08:49 | <othermaciej> | you can’t tack it onto shadow DOM |
| 08:49 | <othermaciej> | because by the time you have some script creating a shadow DOM, it’s too late |
| 08:49 | <othermaciej> | so the mechanism has to come in earlier than that |
| 08:50 | <othermaciej> | I sort of explained it in this email: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0024.html |
| 08:50 | <annevk> | This all sounds quite familiar |
| 08:51 | <othermaciej> | it sounds like XBL2 |
| 08:52 | <annevk> | Heh |
| 08:52 | <othermaciej> | here’s Adam more or less agreeing that my approach is a sensible general direction: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0038.html |
| 08:53 | <annevk> | Did he ever report back? |
| 08:54 | <othermaciej> | not that I recall |
| 08:54 | <othermaciej> | I think he might be mostly working on a non-Blink project these days |
| 08:54 | <annevk> | I got that impression too, hardly see him around anymore |
| 09:00 | <annevk> | I love the latest objection against deprecating synchronous XMLHttpRequest. "Do you really want script writers to deal with scroll events while an ajax is outstanding?" |
| 09:02 | <othermaciej> | I am terrified of the mindset that would produce that comment |
| 11:21 | <JakeA> | annevk: tried to sum up the postMessage stuff over at https://github.com/slightlyoff/ServiceWorker/issues/609#issuecomment-71622477 - let me know if I've gotten any of it wrong |
| 11:22 | <JakeA> | annevk: I'm going to try and get this in front of external devs looking to implement push messaging for their take |
| 11:27 | <annevk> | JakeA: I don't see how you can communicate with Worker and SharedWorker "the standard way" |
| 11:27 | <annevk> | JakeA: it's also not clear to me that complex library usage is going to be discovered early on in the deployment of this, that seems overly optimistic |
| 11:28 | <annevk> | JakeA: I also suggested actually having a MessagePort like object on each side on a per-client basis |
| 11:28 | <JakeA> | annevk: I thought you said it was ok to have instance of dedicatedworker in the serviceworker, and have postMessage work. The standard way with SharedWorker would be the connect event and passing ports through (which I dislike, but it's how it's defined) |
| 11:28 | <annevk> | JakeA: so the object that receives the message can also send is, which happens to be how most of these postMessage() APIs work |
| 11:29 | <annevk> | JakeA: I did at one point, but then later on we figured out that it couldn't possibly work... |
| 11:29 | <annevk> | JakeA: A SW instantiating a Worker/SharedWorker is different from it controlling one |
| 11:30 | <JakeA> | annevk: ohh, I thought it was the other way around, that you thought it couldn't work then realised it could. If a SW gets a reference to a DedicatedWorker via the clients API, what stops it being able to postMessage to it? |
| 11:31 | <annevk> | JakeA: how can two windows possibly have a Worker object that references the same worker? |
| 11:31 | <annevk> | JakeA: s/two windows/two globals/ |
| 11:34 | <JakeA> | Seems like I'm misremembering the history of the dedicated worker bit |
| 11:34 | <JakeA> | annevk: how about SharedWorkers? No problem exposing those right? |
| 11:34 | <annevk> | Same problem |
| 11:34 | <annevk> | I mean, we talked about this, I'm not sure what to say |
| 11:35 | <annevk> | I said several times that Window, Worker, and SharedWorker all need a way, the same way, to receive and post messages to their SW |
| 11:42 | <JakeA> | Fair, I guess getting a SharedWorker would need to be equivalent to constructing a SharedWorker, which could call the connect event, which doesn't really make sense |
| 11:47 | <annevk> | Exactly |
| 11:48 | <annevk> | And DedicatedWorker cannot suddenly go from 1:1 to 1:2 |
| 11:52 | <JakeA> | annevk: "I also suggested actually having a MessagePort like object on each side on a per-client basis" - you weren't happy with navigator.serviceWorker.onmessage being that thing right? |
| 11:53 | <annevk> | JakeA: well, if we always have navigator.serviceWorker.postMessage() to go with it, sure |
| 11:53 | <annevk> | also* |
| 11:53 | <annevk> | I don't really care where we place the endpoints |
| 11:57 | <JakeA> | annevk: The problem is we need to land the message on the client somewhere client specific, a ServiceWorker instance isn't that. But posting from page to ServiceWorker should be serviceWorker.postMessage. SharedWorker gets around this using the connect & posts model which is horrible but also doesn't work with SWs because SWs terminate |
| 11:59 | <JakeA> | annevk: navigator.serviceWorker.onmessage has the benefit of being client specific, lives in ServiceWorker-API space, doesn't interfere with things like window.onmessage, but it doesn't meet the navigator.serviceWorker.postMessage requirement as there no sensible place for that to post to |
| 12:48 | <beverloo> | annevk, is there a mozilla bug for SWR.showNotification()? |
| 12:56 | <annevk> | beverloo: I'm not sure, feel free to file one |
| 12:57 | annevk | finds https://bugzilla.mozilla.org/show_bug.cgi?id=531817 but that seems to be something else |
| 12:57 | <beverloo> | yeah, I found that as well, but that predates the API :) |
| 12:57 | <beverloo> | I'll file one later today |
| 12:57 | <annevk> | JakeA: each global has its own ServiceWorker instance |
| 12:58 | <annevk> | JakeA: and each SW has Client instances |
| 12:58 | <annevk> | JakeA: that seems alright to me |
| 13:00 | <annevk> | JakeA: but I can see how you don't want to to use Client instances as the other side... |
| 13:01 | <annevk> | JakeA: though then you'd need to branch in the onmessage handler on the SW side which doesn't seem great either |
| 13:01 | <annevk> | meh |
| 13:01 | <annevk> | beverloo: ta |
| 13:42 | <jgraham> | Have we considered speccing web components by reality TV show? We lock all the participants in a house with some cameras and every week the public get to vote off whoever isn't providing something useful. At the end of it we either have a spec or everyone involved has killed each other. |
| 13:43 | <annevk> | jgraham: that's your idea of better than the status quo? |
| 13:43 | bkardell | lol annevk |
| 13:43 | <jgraham> | annevk: It seems like you have much better incentives than in the status quo |
| 13:44 | <jgraham> | If you don't do useful things you get voted off and so your opinion is discounted |
| 13:44 | <annevk> | Depends, would there be memes? https://twitter.com/w3cmemes |
| 13:44 | <jgraham> | Also it would provide W3C with a revenue source so they can stop offering jQuery training |
| 13:46 | <jgraham> | I'm sure there would be memes |
| 13:51 | <bkardell> | You know what actually could be intersting - public debates |
| 13:52 | <bkardell> | debate style... moderator, make your case, video stream |
| 13:53 | <bkardell> | I'd watch - I bet I could get a lot of people to watch and comment |
| 14:36 | <annevk> | I don't think that will lead to an inclusive design |
| 14:37 | <annevk> | Though I guess it might be entertaining |
| 15:10 | <wanderview> | JakeA: do you have any sense about how often devs will want to use Cache prefix matching? from chrome telemetry or just talking to folks? |
| 15:26 | gsnedders | wonders what the "Other Data" in the Firefox import is |
| 15:26 | <gsnedders> | That's some nice clear UI. |
| 15:28 | <JakeA> | wanderview: unfortunately it's mostly from my head. I was making sure we had something similar to appcache's FALLBACK matching |
| 15:29 | <JakeA> | wanderview: if there's an implementation concern around it, I'm open to removing it. It's the least important of the match filters |
| 15:29 | <JakeA> | (I think query string ignoring is pretty important) |
| 15:30 | <wanderview> | JakeA: its not a concern per-se... I already have it implemented... but its likely I will optimize non-prefix-matching at the expense of making prefix-matching even slower |
| 15:31 | <wanderview> | JakeA: it comes down to the sqlite schema... the URL text column can be quite large to begin with and using an index on the column essentially duplicates the data on disk again |
| 15:57 | <JonathanNeal> | What if [hidden] accepted a list of media types? I need something like [hidden="screen"] to describe stuff I want hidden from the screen but perceivable to screenreaders. |
| 16:08 | <JakeA> | wanderview: at the moment we have lots of engineers visiting London, which includes the people working on our cache impl. They also see prefix-matching as a deopt. Let's get rid of it! We can always add it back later. |
| 16:08 | <wanderview> | JakeA: actually I need it for a side project I'm working on :-) |
| 16:09 | <wanderview> | but I guess I could skin that cat a different way |
| 16:09 | <JakeA> | wanderview: ohhh interesting. What's the use-case? Is it tough to do without the filter? |
| 16:14 | <wanderview> | JakeA: sent you a private message |
| 16:47 | <JakeA> | annevk: yeah, can't use client.onmessage for client-to-sw messages due to SW termination |
| 16:48 | <JakeA> | stashing ports in SW gives us a way to recreate the SharedWorker style of messaging, but ugh |
| 16:48 | <JakeA> | and also GC observation, potential leaks, and also ugh |
| 16:55 | <annevk> | JakeA: well you could, if all clients are always available |
| 16:56 | <annevk> | JakeA: you'd synchronously register onmessage handlers at the start |
| 16:56 | <annevk> | but it's rather sad |
| 16:58 | <JakeA> | Could hand-wave it to a "clientmessage" global event. But that that point it may as well be onmessage. Hmm. |
| 16:59 | <annevk> | So the annoying thing is that everywhere else the message event protocol avoids branching inside the handler |
| 16:59 | <annevk> | Do service workers already use self.onmessage for something? |
| 17:00 | <annevk> | I wouldn't mind clientmessage to signify its uniqueness, but hmm |
| 17:00 | <JakeA> | annevk: serviceWorker.postMessage ends up there |
| 17:00 | <annevk> | I gotta go, will have more time during the weekend and beyond |
| 17:00 | <JakeA> | That part is similar to dedicated workers |
| 17:00 | <annevk> | Well yes, currently |
| 17:00 | <JakeA> | have a good weekend! |
| 17:01 | <JakeA> | I have a deskbeer so I'm completely useless now |
| 17:09 | <annevk> | you too, but sounds like you started already :-) |
| 20:06 | <dglazkov> | is there something better than lists.w3.org and less smarmy-adsy than Nabble to link to public-webapps discussions? |
| 20:07 | <bkardell> | annevk: you here? |
| 20:08 | <Domenic> | dglazkov: readable-email.org was trying for a while but seems to have not kept up with recent messages :( |
| 20:08 | <Domenic> | dglazkov: oh it seems to have caught up since last I saw it hmm |
| 20:08 | <dglazkov> | that was the best :( |
| 20:08 | <dglazkov> | oh? |
| 20:09 | <dglazkov> | whoa |
| 20:11 | <tantek> | dglazkov - why not post such "emails" on your own site, and only a copy to mailing lists? |
| 20:11 | <dglazkov> | tantek: trying to do the other way around -- excavate old email threads |
| 20:18 | <bkardell> | does it worry anyone that we're shipping prollyfills as prollyfills before they are out of flags or we even have good signals from all the browsers? |
| 20:18 | <bkardell> | arg... shipping prollyfills as polyfills |
| 20:19 | <bkardell> | shouldn't we be more careful about that? otherwise, what's the point in dev'ing them outside a flag? |
| 20:21 | <smaug____> | bkardell: well, who is shipping |
| 20:23 | <bkardell> | smaug___: when I say "we" I mean anyone :) Is it a bad idea |
| 20:23 | <smaug____> | and what do you actually mean. If prollyfill ends up implementing something which never get then implemented after all, users can still use that prollyfill, right? |
| 20:24 | <smaug____> | and then it is just a script library exposing random API not implemented anywhere |
| 20:24 | <bkardell> | smaug___: yes! the problem is what if it doesn't match |
| 20:24 | <smaug____> | s/implemented/implemented natively/ |
| 20:24 | <bkardell> | this is a pattern that needs advice/discussion imo |
| 20:24 | <bkardell> | https://github.com/github/fetch for example - I'm seeing a hella lot of people using that |
| 20:25 | <smaug____> | ah, and then implementations will do something a bit different, and the prollyfill implementation is behind the native implementations ? |
| 20:25 | <bkardell> | but I dont know that we've had any signals from ms or apple at all - say for example - a change is necessary somewhere |
| 20:25 | <smaug____> | right |
| 20:25 | <bkardell> | yes, basically we've seen this happen a buncha times |
| 20:25 | <bkardell> | array contains? |
| 20:26 | <bkardell> | same deal |
| 20:26 | <smaug____> | it would be indeed interesting to hear more feedback from MS and Apple to ServiceWorkers |
| 20:26 | <bkardell> | in the case of fetch promises are kinda done deal, so why not just ._fetch() |
| 20:26 | <bkardell> | if it works for you today it will work for you tomorrow - probably better since browsers tend to get better |
| 20:27 | <bkardell> | if you get lucky, remove the _ |
| 20:27 | <bkardell> | or alias it with native |
| 20:27 | <bkardell> | was thinking of sending that feedback, esp since it is now listed on ft labs polyfill service |
| 20:27 | <bkardell> | I think that is sending mixed messages and creating an issue that is easily avoided |
| 20:28 | <bkardell> | am I making too much of nothing? |
| 20:28 | <tantek> | bkardell: what's the worst that could happen? storage? appcache? |
| 20:29 | <bkardell> | tantek: how is appcache related? |
| 20:29 | <tantek> | just a couple of problematic APIs off the top of my head |
| 20:29 | <tantek> | *local storage |
| 20:29 | <bkardell> | ah |
| 20:29 | <smaug____> | storage and appcache were both real things |
| 20:29 | <bkardell> | no I am thinking more like Array.prototype.contains |
| 20:29 | <smaug____> | which the later were noticed to be rather bad ones |
| 20:29 | <smaug____> | then |
| 20:30 | <bkardell> | ES had to change it at the last minute because you can't - you'll break web stuff |
| 20:30 | <tantek> | bkardell: then could prollyfills help avoid the "later noticed" problem and notice sooner when APIs are bad? |
| 20:30 | <bkardell> | tantek: sure, you could - that's part of the idea |
| 20:31 | <bkardell> | tantek: like, we put native implementations behind a flag - we used to prefix them - to tell people "these are experimental" |
| 20:31 | <bkardell> | but we found that that is a footgun |
| 20:31 | <bkardell> | a prollyfill is a way to stride the chasm |
| 20:31 | <smaug____> | I guess it is mainly about when one can think some API is "stable" |
| 20:31 | <smaug____> | and that depends on who to ask |
| 20:32 | <bkardell> | yeah, and it's kinda what I'm saying... it's about managing risk and I dont know how risky it is in this particular case |
| 20:32 | <tantek> | smaug____: clearly "stable" != good |
| 20:32 | <bkardell> | I do know though that there's no signals at all from apple and ms has, according to chrome status, given mixed signals |
| 20:32 | <tantek> | or not necessarily |
| 20:32 | <smaug____> | tantek: indeed, but stable is usually something browsers ends up shipping |
| 20:33 | <smaug____> | we haven't removed that many APIs |
| 20:33 | <bkardell> | but especially in this case, it seems easy to avoid the worst risk |
| 20:33 | <bkardell> | by just saying underscore the prollyfill |
| 20:33 | <bkardell> | since it's api has no complex intertwined dependencies, it's basically one method |
| 20:34 | <bkardell> | so... is it crazy to suggest that? am I tilting at windmills needlessly? |
| 20:37 | <bkardell> | it feels like so close to really good - if it goes wrong, that will be sad |
| 20:38 | <JonathanNeal> | bkardell: what about ft polyfill? =) |
| 20:38 | <bkardell> | good! you are on! |
| 20:38 | <bkardell> | read above |
| 20:39 | <JonathanNeal> | i did, but i didn’t follow the conversation. |
| 20:39 | <bkardell> | starting http://krijnhoetmer.nl/irc-logs/whatwg/20150206#l-592 |
| 20:40 | <bkardell> | is it still unclear? |
| 20:40 | <JonathanNeal> | Yea, polyfill is pretty aggressive, but unlike browsers, users can stick to one version of an api. |
| 20:41 | <bkardell> | they can until there is a true version which claims to be the same version |
| 20:41 | <bkardell> | right? |
| 20:41 | <JonathanNeal> | It would be like if you could ‘use strict 1.5.2’; in js. |
| 20:41 | <bkardell> | that will present a problem |
| 20:41 | <bkardell> | say the draft today says the api should look like foo(x, y) |
| 20:42 | <JonathanNeal> | Yea … you are touching on something I wanted to see, which is levels of polyfill compliance. |
| 20:42 | <bkardell> | well, this is pretty simple to avoid - just use ._fetch |
| 20:42 | <JonathanNeal> | You’re not really using a polyfill as a polyfill then. |
| 20:43 | <bkardell> | I'm suggesting simply we dont claim to be the real thing until we can say for sure what the real thing is |
| 20:43 | <bkardell> | it's not a polyfill |
| 20:43 | <bkardell> | its a prollyfill |
| 20:43 | <bkardell> | the lack of distinction is the part that worries me |
| 20:43 | <JonathanNeal> | bkardell: we never claim, we wait for a spec, and the only difference between a prollyfill and a polyfill is an implementation not behind a flag. |
| 20:44 | <JonathanNeal> | i know because i usually write prollyfills before a spec exists, but I’ve protected myself from allowing them into the project until I see a spec. .closest was a good example. |
| 20:44 | <bkardell> | you're misreading my point, I'm not saying you claim as in you state it in words |
| 20:45 | <JonathanNeal> | You mean, we treat prollyfills and polyfills the same, and people are probably leveraging prollyfills (instead of just polyfills) more and more? |
| 20:45 | <bkardell> | JonathanNeal: no, that's a good thing - it's what I want... I just want them to do it safely. Appearance in a spec definitely does not mean that that is what we will get |
| 20:45 | <JonathanNeal> | And that’s dangerous if the functionality changes between the prollyfill and the real thing? |
| 20:45 | <bkardell> | yes! |
| 20:46 | <bkardell> | not just dangerous in code though - browsers and standards care |
| 20:46 | <JonathanNeal> | Yea. The problem with prefixing apis is that people never unprefix them. |
| 20:46 | <bkardell> | doesn't matter if you unprefix fetch or not in this case, does it? |
| 20:47 | <JonathanNeal> | Unless every api some kind of .spec or .lastUpdated key we could reference to know whether or not we should use native functionality. |
| 20:47 | <bkardell> | if you were so lucky as to have it match then you could simply say _fetch = fetch; and be done |
| 20:47 | <JonathanNeal> | Alternatively, I see people doing very complex tests before a polyfills to determine if the polyfill should deploy. |
| 20:48 | <bkardell> | I dont understand why that matters tho... that's about browsers prefixing which they have basically agreed to stop doing and put behind a flag for basically this reason |
| 20:49 | <JonathanNeal> | Yea, but when the functionality is really desired, the moment it appears in a spec, we’re gonna get an issue filed to include it. |
| 20:49 | <bkardell> | if you write code that uses an experimental thing, but you also provide the experimental implementation (prollyfill) you can go about your day - job done |
| 20:49 | <bkardell> | so include it, I love that! |
| 20:49 | <JonathanNeal> | Same for when something changes, it’s within hours. |
| 20:49 | <bkardell> | just asking that we do _fetch or something instead of .fetch |
| 20:49 | <bkardell> | at least until we're pretty sure |
| 20:49 | <JonathanNeal> | yea but what if the name changes. |
| 20:49 | <bkardell> | what name changes? |
| 20:49 | <JonathanNeal> | _fetch becomes _get or something |
| 20:49 | <bkardell> | do you want to take this privately or is anyone else interested? |
| 20:50 | <JonathanNeal> | _has becomes _contains, etc. |
| 20:50 | <JonathanNeal> | I don’t have a solution, but I think the problem you are describing is a big web question. |
| 20:50 | <lerc> | Did the canvas on worker porposal go anywhere? https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html |
| 20:51 | <JonathanNeal> | In a world with evergreen browsers, who’s going to wait for native functionality anymore? |
| 21:03 | <Domenic> | People who don't want to wait for stuff to go through standardization before using it |
| 21:03 | <Domenic> | i.e., the "why can't I track steps using a web app" problem |
| 21:10 | <bkardell> | Domenic: Are you under the impression that that is what I am suggesting in some way? |
| 21:11 | <Domenic> | bkardell: nope, just responding to JonathanNeal's perspective. |
| 21:11 | <Domenic> | s/perspective/question |
| 21:15 | <bkardell> | Domenic: Yeah, that would have suprised me :) |