| 08:10 | <annevk> | es-discuss proves the trivial topic thing once again... "How should we refer to JavaScript?" Oooh, lets write 50 emails within twelve hours! |
| 08:10 | <annevk> | let's |
| 08:11 | <zcorpan> | i wonder if Spartan has any use of quirks.spec.whatwg.org |
| 08:18 | <annevk> | Probably, it's just a major refactoring of Trident from what I heard |
| 08:19 | <annevk> | Though the details of what that means are somewhat unclear |
| 08:27 | <zcorpan> | i mean since they got rid of their document modes |
| 10:13 | <zcorpan> | <!--[if IE ]> |
| 10:13 | <zcorpan> | <!doctype html> |
| 10:13 | <zcorpan> | <![endif]--> |
| 10:13 | <zcorpan> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">; |
| 10:13 | <zcorpan> | view-source:http://www.telegraph.co.uk/ |
| 10:25 | <jgraham> | Hahaha |
| 11:18 | <zcorpan> | hsivonen: time to update https://hsivonen.fi/doctype/ about IE11 and Edge? |
| 11:22 | <zcorpan> | hsivonen: also s/(which in invalid in HTML5)//g |
| 11:23 | <zcorpan> | hmm, i had forgotten about Chrome Frame |
| 12:13 | <hsivonen> | zcorpan: yeah, I should find the time to update the doctype article |
| 12:19 | hemanth | Just made a riotjs timer demo -> http://jsbin.com/dopedo/ |
| 16:00 | <Domenic> | annevk: I don't really understand the issue or question in https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-71176152 |
| 16:46 | <annevk> | Domenic: we want Response to have some mutable state |
| 16:46 | <annevk> | Domenic: question is mostly whether respondWith should halt the mutability |
| 16:51 | <Domenic> | annevk: what about "do we expect the Response object to be cloned at that point in a JavaScript-only world?" ? That part seems especially confusing, possibly because I don't understand respondWith |
| 16:52 | <annevk> | Domenic: so you have document A and service worker SW |
| 16:52 | <annevk> | Domenic: SW has a Response object and hands it back to some fetch from A |
| 16:52 | <annevk> | Domenic: how would that work? |
| 16:54 | <Domenic> | "hands it back to some fetch from A" does this involve running any code in A? Or is the code entirely in the SW? |
| 16:56 | <annevk> | Domenic: I was trying to reason from a platform-implemented-in-JS-perspective |
| 16:56 | <Domenic> | Yeah, me too :) |
| 16:56 | <annevk> | Domenic: well for A to do a fetch, code has to run, no? |
| 16:56 | <Domenic> | ok, so A's JS code does fetch(req) |
| 16:57 | <Domenic> | SW's js code does .onfetch = function (e) { e.respondWith(new Response(...)); } |
| 16:58 | <Domenic> | A's JS code gets back a Response object from the promise callback |
| 16:58 | <Domenic> | Is the question then about the relation between the `new Response(...)` in SW and the Response A gets back in the promise callback? |
| 17:06 | <annevk> | Domenic: yeah |
| 17:07 | <annevk> | Domenic: and in particular up until what point mutations to it in SW affect what A sees |
| 17:07 | <Domenic> | annevk: OK so in that case I think they're definitely cloned, even in pure-JS land. Since it's across "vats" which are super-separated. |
| 17:07 | <Domenic> | annevk: so the question would be when exactly the cloning happens I guess. |
| 17:07 | <annevk> | Domenic: and whether the object remaining in SW needs to be guarded at some point to further mutations |
| 17:09 | <Domenic> | annevk: I would naively guess the cloning happens when the promise you pass to respondWith() has its IDL-registered set of callbacks run |
| 17:12 | <annevk> | Domenic: yeah agreed |
| 17:12 | <annevk> | Domenic: I arrived at that conclusion too |
| 17:12 | <annevk> | Domenic: just not sure how to write this out |
| 17:12 | <annevk> | Domenic: should respondWith set a flag on Response that prevents further mutation? |
| 17:13 | <Domenic> | Meh, I'm not sure users need to be protected that much. Is this the first mutable state on Response? |
| 17:14 | <Domenic> | You'd have to define that the internal slot gets cloned as part of structured clone, for sure. |
| 17:15 | <annevk> | So we can't call devs authors, but users is okay? |
| 17:19 | <caitp> | authors, editors, biographers, depends what they're developing :u |
| 17:23 | <Domenic> | Blah I am used to saying "users" from all the io.js I've been doing recently |
| 17:46 | <Ms2ger> | TabAtkins, you should bikeshed FileAPI some time |
| 18:29 | <JonathanNeal> | I’m a little unclear on DOM4’s .append method. Will it apply to just Element or Node as well (for document.append usage)? |
| 18:35 | <caitp> | i believe that applies to the ParentNode partial interface |
| 18:35 | <caitp> | so Element, Document and DocumentFragment |
| 18:39 | <JonathanNeal> | caitp: excellent. |
| 18:40 | <JonathanNeal> | Does that mean I would find it on the Node prototype? Or only on ParentNode? |
| 18:40 | <caitp> | well there's no ParentNode exposed to Js |
| 18:40 | <caitp> | you'd see the methods of ParentNode in the interfaces i listed above |
| 18:43 | <Ms2ger> | What does the spec say? |
| 18:44 | <JonathanNeal> | Ms2ger: that’s what I was having trouble following and decided to asked about. |
| 18:44 | <Ms2ger> | Document implements ParentNode; DocumentFragment implements ParentNode; Element implements ParentNode; |
| 18:45 | <Ms2ger> | So it's on Document.prototype, DocumentFragment.prototype, and Element.prototype |
| 18:45 | <caitp> | eg, if you wanted to polyfill it, you'd have to do it for each of those |
| 18:45 | <JonathanNeal> | That’s very helpful. Thanks. |
| 18:47 | <Ms2ger> | Relevant spec is https://heycam.github.io/webidl/#es-implements-statements |
| 18:53 | <TabAtkins> | Ms2ger: Where's it stored? |
| 18:55 | <TabAtkins> | I also really wanna Bikeshed DOM, as there's always tons of links to that from these JS-heavy specs. |
| 18:56 | <TabAtkins> | It's gotten a lot easier to link to non-Bikeshedded specs now, but still not 0 effort, so I have work to do. |
| 18:59 | <JonathanNeal> | Nice close, caitp. |
| 18:59 | <caitp> | huh? |
| 19:01 | <JonathanNeal> | https://github.com/angular/angular.js/issues/9967 ? |
| 19:01 | <manu> | anyone on this channel know what the current state of the art is wrt. browsers communicating w/ native apps? If I want my website to trigger a native app to handle a payment, for example. What would folks suggest? |
| 19:01 | <caitp> | heh, it probably wasn't going to happen |
| 19:02 | <JonathanNeal> | caitp: they do it over at https://octane.github.io/promise/tests/browser.html |
| 19:02 | <manu> | so, browser page sends JSON data to native app, JSON data is processed by native app and response is sent back to browser page. |
| 19:02 | <manu> | is postMessage() + offline mode the "best" way to accomplish something like this nowadays? |
| 19:04 | <manu> | (given that web intents is dead?) |
| 19:42 | <JonathanNeal> | Would this be a good doc to fork if I wanted to suggest features? |
| 19:45 | <JonathanNeal> | ^ https://github.com/WebReflection/dom4 |
| 19:46 | <JonathanNeal> | WRONG |
| 19:46 | <JonathanNeal> | Ahem https://github.com/whatwg/dom |
| 19:48 | <JonathanNeal> | When did replace become replaceWith? How can I keep up to date with these changes? |
| 19:54 | <miketaylr> | just a few days ago JonathanNeal |
| 19:54 | <Domenic> | JonathanNeal: https://github.com/whatwg/dom/commits/master seems like a good way to do so. There's even RSS: https://feedly.com/i/subscription/feed/https://github.com/whatwg/dom/commits/master.atom |
| 20:00 | <JonathanNeal> | @Domenic great you just tell me where I can stuff forEach =D |
| 20:00 | <Domenic> | JonathanNeal: already there: https://dom.spec.whatwg.org/#collections:-elements |
| 20:02 | <JonathanNeal> | So, for polyfilling, Elements can mirror to NodeList? And HTMLCollection is the older, living collection version, right? |
| 20:03 | <Domenic> | I don't know what "mirror to NodeList" means |
| 20:04 | <JonathanNeal> | Until I see global.Elements, I can expect Elements = NodeList? |
| 20:04 | <Domenic> | The main difference between NodeList and HTMLCollection is the former contains nodes and the latter contains elements |
| 20:04 | <Domenic> | No, you cannot... they are different things entirely. |
| 20:05 | <JonathanNeal> | Okay, so querySelectorAll and childNodes will still return NodeList or will they return Elements? |
| 20:05 | <Domenic> | They will return NodeList |
| 20:06 | <Domenic> | Which can never have forEach per https://stackoverflow.com/questions/13433799/why-doesnt-nodelist-have-foreach/27024188#27024188 |
| 20:06 | <JonathanNeal> | There’s this line in the spec “It's the new NodeList / HTMLCollection.” |
| 20:06 | <Domenic> | Yes. That doesn't change what other things return. |
| 20:07 | <JonathanNeal> | Having it on query but not nodeList will probably bum folks out. |
| 20:08 | <JonathanNeal> | Despite the concat bug. |
| 20:08 | <Domenic> | The hope is in the beautiful future you won't be seeing many NodeLists |
| 20:09 | <JonathanNeal> | How does that happen? Are there significant changes to DOM traversing coming? |
| 20:12 | <Domenic> | Well .queryAll() will take care of many cases |
| 20:12 | <JonathanNeal> | Ah, so like queryAll(':nth-child(n)’) ? |
| 20:12 | <Domenic> | I... don't know why you would ever do that. |
| 20:13 | <JonathanNeal> | I … want a Elements collection. =) |
| 20:13 | <Domenic> | what elements are represented by :nth-child(n) |
| 20:13 | <Domenic> | Is that the same as "> *" |
| 20:13 | <JonathanNeal> | Sure, either selector. |
| 20:13 | <Domenic> | No I think it's the same as "*" |
| 20:14 | <Domenic> | But yes, in general, use .queryAll("> *") instead of .children, etc. |
| 20:14 | <JonathanNeal> | So, folks would need to queryAll(‘>*’) ? |
| 20:15 | <Domenic> | Maybe we add more aliases once the very basic part of the idea proves its worth |
| 20:15 | <Domenic> | although with children and childNodes it's already getting kind of crowded in there |
| 20:15 | <JonathanNeal> | And this is to avoid the thing with named properties on HTMLCollection and concat treating non-array-iterables weird? |
| 20:16 | <Domenic> | yeah basically. stated more generally, to avoid the problem where making NodeList or HTMLCollection subclass Array breaks the web. |
| 20:16 | <Domenic> | You also get benefits that .queryAll("> *") actually works, whereas .querySelectorAll("> *") throws, because of the slightly-better way in which queryAll interprets selectors |
| 20:18 | <JonathanNeal> | I’ve been eager for queryAll since Resig blogged about the issues with querySelectorAll. |
| 20:19 | <JonathanNeal> | I am surprised browsers weren’t faster to adopt it, but I guess it’s a win for the Elements class. |
| 20:21 | <Domenic> | They're waiting for ES6 subclassing to work |
| 20:22 | <TabAtkins> | Domenic: :nth-child(n) is identical to "*". |
| 20:22 | <TabAtkins> | Except for specificity, which doesn't matter here. ^_^ |
| 20:22 | <JonathanNeal> | I just wanted to write something worse than *, is all. |
| 20:50 | <JonathanNeal> | Anything going on spec-wise with event listeners / handlers or event delegation? |
| 21:24 | <TabAtkins> | Anyone know where the File API source is kept? Can't find if there's a github or something for it. |
| 21:25 | <tantek> | probably in a file system |
| 21:25 | <TabAtkins> | You lose 1 point for purposeful obtuseness. |
| 21:26 | <tantek> | File / file? too obv? sorry. |
| 21:26 | <TabAtkins> | No, no, I got it. You still lose the point. |
| 21:27 | <TabAtkins> | I wanna Bikeshed it, but dunno where it's kept; I'd vastly prefer messing with the source over the generated output. |
| 21:36 | <TabAtkins> | annevk: Could I Bikeshed DOM? |
| 21:40 | <JonathanNeal> | Hey, we might all have opinions on bikeshedding that should be discussed before you go and bikeshed. |
| 21:40 | <TabAtkins> | Not allowed. |