| 00:30 | <MikeSmith> | jsbell: So, we really need a new, active editor for the File API spec |
| 00:30 | <MikeSmith> | we've got open bugs and of course other specs depending on it |
| 00:31 | <MikeSmith> | hoping you might be able to help surface a new editor for it |
| 00:32 | <MikeSmith> | maybe in consultation with slightlyoff |
| 00:33 | <MikeSmith> | however y'all make the magic |
| 00:48 | <jsbell> | MikeSmith: I'll see what we can wrangle. |
| 00:56 | <rniwa> | can someone review my PR request for template element test? https://github.com/w3c/web-platform-tests/pull/2651 |
| 00:59 | <jsbell> | MikeSmith: out of curiosity, is the current spec hand-authored as it appears (i.e. not respec/bs, etc) ? |
| 01:00 | <jsbell> | kinda looks like respec output... |
| 01:30 | <TabAtkins> | jsbell: I pushed a bikeshedded version a while ago. |
| 01:31 | <TabAtkins> | jsbell: There's a PR open that hasn't been merged yet for it. :/ |
| 02:13 | <Domenic> | Just two days of custom elements spec work and I am immensely sick of Respec's flash-of-losing-my-scroll-position |
| 03:35 | <rniwa> | Domenic: yt? |
| 03:35 | <rniwa> | annevk: yt? |
| 03:36 | <Domenic> | rniwa: yep |
| 03:36 | <rniwa> | Domenic: hi |
| 03:36 | <rniwa> | Domenic: we have one "minor" problem with regards to finding the right registry |
| 03:36 | <rniwa> | Domenic: when you create a document via DOMImplementation |
| 03:36 | <Domenic> | hmmmm |
| 03:36 | <rniwa> | Domenic: and author calls defineElement on it |
| 03:37 | <rniwa> | Domenic: and HTMLElement's constructor is called in super() |
| 03:37 | <rniwa> | Domenic: the global object isn't associated with THAT document |
| 03:37 | <Domenic> | yeah |
| 03:37 | <Domenic> | that is broken |
| 03:37 | <Domenic> | ok |
| 03:38 | <Domenic> | so i think each registration needs to store its document too? |
| 03:38 | <Domenic> | wait no that doesn't work |
| 03:38 | <Domenic> | hmm maybe not best to think about this at the end of a long day |
| 03:38 | <Domenic> | File the issue and we'll figure it out tomorrow? |
| 03:38 | <Domenic> | This is tricky... |
| 03:39 | <Domenic> | I am not sure it is solvable |
| 03:39 | <Domenic> | for the new CustomElement() case there's just no way to know |
| 03:43 | <rniwa> | Domenic: indeed. |
| 03:45 | <Domenic> | this seems like a more general problem with non-1:1 document:windows |
| 03:45 | <pwf> | hello! is there a transform implemented in any major browser that would let me stream lines from a web request? |
| 03:45 | <Domenic> | which I guess includes 1-window-2-documents for initial about:blank navigation |
| 03:45 | <rniwa> | Domenic: we don't even know what to do with document.createElement either |
| 03:46 | <Domenic> | and 1-document-several-windows for document.open() |
| 03:46 | <rniwa> | Domenic: since you can create yourself with another document before calling super() |
| 03:46 | <pwf> | the streams spec looks like exactly what i want, but i don't know who's implemented the bits i want (or if there are any examples of it...) |
| 03:47 | <Domenic> | pwf: Chrome has implemented streaming bodies. https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html https://jakearchibald.com/2016/streams-ftw/ |
| 03:47 | <Domenic> | rniwa: sure, but that's one of those "don't do that" scenarios I guess |
| 03:47 | <pwf> | that's the article that led me here haha |
| 03:47 | <rniwa> | Domenic: well, the problem is that people WILL do it |
| 03:47 | <rniwa> | Domenic: and we have to define the behavior |
| 03:47 | <Domenic> | right, certainly |
| 03:48 | <Domenic> | it just might do something weird |
| 03:48 | <pwf> | oh wait, the 2015 one did! i haven't seen the 2016 one, thank you! |
| 03:48 | <Domenic> | and i'm ok with that |
| 03:48 | <Domenic> | new CustomElement() not working seems bad though |
| 03:48 | <rniwa> | Domenic: so I think we need to create in the global object's document and adopt it |
| 03:48 | <Domenic> | i see |
| 03:48 | <rniwa> | Domenic: it's okay to do this because all prototype objects, etc... are the same |
| 03:49 | <rniwa> | Domenic: there is no issue of identify (e.g. misleading instanceof behavior) |
| 03:49 | <Domenic> | i dunno i am starting to feel we should go back to not allowing implementation.createHTMLDocument()? |
| 03:50 | <rniwa> | Domenic: well, we need to solve this problem regardless if we ever wanted to allow custom registry |
| 03:50 | <pwf> | is there a list of the decoders/pipes already built into chrome Domenic? like one that grabs lines for me maybe? |
| 03:50 | <Domenic> | pwf: nothing is built-in; you write your own |
| 03:50 | <Domenic> | i guess we could make it work but it seems bad that you do doc.defineElement("x-foo", CE) and then new CE() always fails |
| 03:52 | <rniwa> | Domenic: no, CE() will work in that case |
| 03:52 | <rniwa> | new CE()* |
| 03:52 | <Domenic> | here doc = document.implementation.createHTMLDocument(). How will it work? |
| 03:53 | <rniwa> | Domenic: we just need not to throw TypeError in steps 3 and 4 of HTMLElement constructor |
| 03:53 | <rniwa> | Domenic: basically allow any constructor to call HTMLElement's constructor |
| 03:53 | <Domenic> | hmmmm |
| 03:53 | <rniwa> | Domenic: as long as its [[Prototype]] eventually leads to HTMLElement |
| 03:53 | <rniwa> | its=new.target |
| 03:54 | <rniwa> | Domenic: this would mean that you can do new (class extends HTMLElement{}) |
| 03:54 | <rniwa> | Domenic: without ever calling defineElement though... |
| 03:54 | <Domenic> | yeah what would that even give you |
| 03:54 | <Domenic> | what is its tagname etc. |
| 03:54 | <rniwa> | oh wait... |
| 03:54 | <rniwa> | yeah, :( |
| 03:54 | <rniwa> | we don't know the tag name |
| 03:54 | <Domenic> | if we had a real HTMLElement constructor this would be solvable |
| 03:55 | <rniwa> | Domenic: actually, this was the reason my HTMLElement constructor took the tagname as an argument |
| 03:55 | <Domenic> | https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L113 |
| 03:55 | <rniwa> | Domenic: but even if you did, it still woudln't work because you can't verify whether that tagname is associated with the particular interface or not |
| 03:55 | <Domenic> | delegates to https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L31 |
| 03:55 | <rniwa> | Domenic: in particular, it's possible for super() call to be made with a "wrong" new.target |
| 03:55 | <Domenic> | it needs a document argument too |
| 03:56 | <rniwa> | Domenic: and there will be no way of knowing that |
| 03:56 | <rniwa> | Domenic: I think the easiest thing to do will be accepting an optional document argument in HTMLElement's constructor |
| 03:57 | <rniwa> | Domenic: and make Construct call pass in the document |
| 03:57 | <rniwa> | Domenic: so that in common case, author can omit it |
| 03:57 | <Domenic> | rniwa: do you actually expect authors to write super({ document: some particular document }) though? |
| 03:57 | <rniwa> | Domenic: but if they wanted to, they can pass along document to support window-less document to create their own registry |
| 03:57 | <rniwa> | Domenic: ugh... it's not do another dictionary |
| 03:57 | <Domenic> | hmm hmm |
| 03:57 | <rniwa> | Domenic: lets* |
| 03:58 | <rniwa> | Domenic: no, I'd expect authors to write |
| 03:58 | <Domenic> | no please let's there's so many params, they need names |
| 03:58 | <rniwa> | constructors(...args) { super(...args); ... } |
| 03:58 | <Domenic> | i see |
| 03:58 | <rniwa> | Domenic: I really don't want to use Dictionary here |
| 03:58 | <Domenic> | why? |
| 03:58 | <rniwa> | Domenic: if anything, we should create an opaque object authors can't mess with it |
| 03:58 | <Domenic> | this is classic dictionary stuff. a bunch of optional options. |
| 03:58 | <rniwa> | Domenic: performance |
| 03:59 | <Domenic> | make a fast path for undefined? |
| 03:59 | <rniwa> | Domenic: no, I'd make them required if anything |
| 03:59 | <Domenic> | that might be better |
| 03:59 | <rniwa> | Domenic: I'd be strongly opposed to making this dictionary |
| 03:59 | <Domenic> | rniwa: well i'd be strongly opposed to it not being a dictionary |
| 03:59 | <rniwa> | Domenic: okay, so no argument to super() |
| 03:59 | <rniwa> | Domenic: let |
| 03:59 | <rniwa> | let's not support multiple registries per window |
| 04:00 | <Domenic> | SGTM :D |
| 04:03 | <rniwa> | Domenic: a funny thing is, the spec currently says that already LOL |
| 04:04 | <rniwa> | Domenic: https://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries |
| 04:04 | <Domenic> | rniwa: haha right, i guess so. |
| 04:08 | <pwf> | what's the buffer size on reader.read(),then(some_function)? i plan on abusing it like i would a websocket only without messing with websockets |
| 04:08 | <pwf> | in my testing it seems like i can just ignore the fact that a 'message'/'chunk'/whatever will end halfway through |
| 04:11 | <rniwa> | Domenic: document.open replaces the global object!? |
| 04:12 | <rniwa> | Domenic: or did you mean window.open? |
| 04:15 | <Domenic> | rniwa: nope, document.open |
| 04:16 | <Domenic> | rniwa: it kind of tears down the document, then creates a new window, and sets that window's document to the document being document.open()ed |
| 04:16 | <Domenic> | https://html.spec.whatwg.org/#dom-document-open |
| 04:17 | <pwf> | ok it turns out ignoring buffer size on read did indeed bite me... |
| 04:17 | <Domenic> | pwf: the buffer size is "however many bytes network conditions dictate". You shouldn't rely on it. |
| 04:18 | <pwf> | {"image": "images/test_50.png", "iteration": "50"} |
| 04:18 | <pwf> | poop.html:15 Uncaught (in promise) SyntaxError: Unexpected token o |
| 04:18 | <pwf> | errr... ignore my filename |
| 04:19 | <pwf> | why did console.log get a full json object but i couldn't decode it? |
| 04:22 | <pwf> | ohh... i'm using result instead of the return value of decoder.decode |
| 06:12 | <rniwa> | Domenic: it seems that the corollary of that discussion is that we also need to disallow defineElement on template.content |
| 06:13 | <rniwa> | Domenic: because we're going to face the same issue |
| 06:19 | <annevk> | rniwa: yeah, that's a different document too so falls out naturally |
| 06:20 | <annevk> | rniwa: this was bz's concern with new Text and such, there we simply pick a document from a global |
| 06:21 | <rniwa> | annevk: yeah, now I remember that discussion |
| 06:21 | <rniwa> | annevk: it's funny how we keep re-discovering the same problem :( |
| 06:21 | <rniwa> | one of these days, i'm gonna improve my long term memory... |
| 06:22 | <annevk> | rniwa: I'm surprised actually that it took until now for this to become really clear |
| 06:23 | <annevk> | rniwa: should have been clear to custom elements folks long ago I'd think and documented |
| 06:24 | <rniwa> | annevk: I think the problem is that people who worked on v0 aren't actively participating in this discussion |
| 06:52 | <annevk> | Seems likely, but v0 never worked this through either I think |
| 08:05 | <annevk> | Oh yes, someone else is removing CanvasProxy \o/ |
| 09:04 | <zcorpan> | gah someone please fix svg favicons, i can't find the html standard among my open tabs anymore :-( |
| 09:21 | annevk | wonders if he can convince someone else to review some new URL tests |
| 09:22 | <annevk> | zcorpan: use Firefox? |
| 09:23 | <zcorpan> | annevk: yeah, or I could use Opera 12 :-) |
| 09:23 | <annevk> | zcorpan: I see you value your security |
| 09:26 | <zcorpan> | yep, i use passwords that are hard to remember! |
| 09:26 | <zcorpan> | (true story) |
| 11:14 | <hgl> | what do you guys think about the react trend? i feel like it's trying to hide people from DOM. with react, every change to DOM should go through the vdom. i don't think every kind of ui can be expressed by vdom, and it's pretty awkward too when it comes to animations. why browsers can't offer a declarative api and figure our the minimal dom change? i think that's the core value of react. |
| 11:15 | <annevk> | hgl: it's not that simply, unfortunately |
| 11:16 | <hgl> | annevk: care to explain some details? tree comparison is too expensive for browsers to do? |
| 11:17 | <annevk> | hgl: the diffing is not really the important thing |
| 11:17 | <annevk> | hgl: the important thing is that react uses DOM as a render step |
| 11:17 | <annevk> | hgl: so they only change the DOM when they want to render |
| 11:18 | <annevk> | hgl: providing more control over when rendering happens, or maybe having some kind of batching thing for DOM mutations, might help, but it's tricky to unravel all that |
| 11:21 | <hgl> | annevk, i don't quite understand what you mean by using DOM as a render step? if node provide an api like, node.render(template), where template is the template element containing the final node structure and browser will figure out the minimal steps to render the children of node, and people only call it when they want to "render", isn't it the same thing as react? |
| 11:24 | <annevk> | I don't see how that would solve any of the problems |
| 11:24 | <annevk> | Unless you don't care about the DOM as the source of truth |
| 11:26 | <hgl> | maybe i didn't look at react/dom from a right angle, but for me, the advantage of react is i don't have to do the imperative steps to bring DOM to a structure i want. with react, i just tell it the structure i want, and it'll figure all the imperative steps for me. i thoughts this tedious process was that react tried to solve? |
| 11:27 | <hgl> | (being a non-native speaker, i miss the ability to edit my messages in slack :) |
| 11:32 | <hgl> | put it another way, i see react as a mapping engine that maps data to dom structure. i specify the mapping, and give it the data, i get correct dom structure out. |
| 11:32 | <annevk> | The problem with not treating the DOM as the source of truth but some parallel object model is that any references to DOM objects get destroyed, updates to DOM objects might get lost, state in DOM objects might get lost, etc. |
| 11:33 | <annevk> | There's this mantra around react that updating DOM is expensive, but what's expensive is layout, not the DOM, that's just a data structure |
| 11:35 | <hgl> | yeah, that's exactly why i want browsers to have such api, so they can use real DOM as the "parallel object model", i hate this parallel object model (vdom) from react... |
| 11:36 | <nox> | How would that API work? |
| 11:36 | <nox> | What is 'template'? |
| 11:36 | <hgl> | because i can no longer touch dom myself... all changes i want to make, i need to go though this parallel object |
| 11:36 | <nox> | How do you enforce you didn't touch DOM yourself? |
| 11:36 | <hgl> | umm, something like <template><div></div></template>? |
| 11:37 | <nox> | That's still DOM? |
| 11:37 | <hgl> | yes, like your put this string in html, ask browsers to turn it into dom, then pass the template element to node.render(template) |
| 11:38 | <hgl> | the point of making browsers to have this API, is that i hope i can mix and match declarative & imperative ways to manipulate DOM |
| 11:38 | <nox> | I don't get the advantage over just using the DOM in that template. |
| 11:41 | <nox> | annevk: Mmmh, I'm confused, is "replace all with node within a parent" actually bound to any DOM method? |
| 11:41 | <annevk> | nox: innerHTML |
| 11:41 | <nox> | annevk: Ah. |
| 11:41 | <annevk> | nox: textContent |
| 11:41 | <nox> | annevk: Was looking for innerHTML. |
| 11:42 | <nox> | annevk: Couldn't find a case in the DOM spec where the DocumentFragment case was used. |
| 11:42 | <annevk> | nox: innerHTML is the DocumentFragment case |
| 11:42 | <annevk> | heh |
| 11:42 | <nox> | :) |
| 11:42 | <hgl> | nox, oh, do you mean i should just do node.textContent = ''; node.appendChild(template.childNode[0])? |
| 11:42 | <nox> | annevk: Was wondering if hgl would be satistfied by a node.replaceAllChildren(template.cloneNode(true)). |
| 11:42 | <nox> | Well, not template, but the document fragment inside. |
| 11:43 | <nox> | hgl: Anyway, I don't see what your proposal avoids. |
| 11:43 | <nox> | It's still the DOM, you can still access it in many ways, etc. |
| 11:44 | <hgl> | i see what you mean... |
| 11:44 | <hgl> | maybe i should put it this way |
| 11:45 | <hgl> | i'd like template element to let me insert data declaratively... <template><div>{obj.prop}</div></template> |
| 11:46 | <nox> | Sounds like you want slots and things like that. |
| 11:46 | <hgl> | currently if you want a template to contain data, the imperative steps to fill it can be huge |
| 11:46 | <hgl> | wow, slots? it already supports something like that? |
| 11:46 | <nox> | hgl: https://webkit.org/blog/4096/introducing-shadow-dom-api/ |
| 11:46 | <hgl> | does a spec exist? |
| 11:47 | <nox> | No idea what the status of this is, I'm a newcomer around here. |
| 11:48 | <annevk> | It's at the point where we've done the first 80% and are now figuring out the remaining 80% |
| 11:48 | <hgl> | first 80% and remaining 80%..... what happened... |
| 11:53 | <hgl> | nox, annevk, slots look like what i wanted, very cool, thank for letting me know... |
| 11:59 | <annevk> | JakeA: https://twitter.com/jaffathecake/status/705355715414781953 is pretty compelling |
| 12:00 | <JakeA> | agreed, as more elements are added to that demo, Servo hits a JS bottleneck way before paint |
| 12:01 | <jgraham> | Yeah, the main problem with servo is the sheer amount of junk you need to make a web browser these days |
| 12:01 | <JakeA> | With Chrome's GPU renderer (which isn't the one I used in the recording), its GPU stuff is the bottle neck. Lack of batching I think. |
| 12:01 | <annevk> | It's about time layout get its "order of magnitude" improvement now JavaScript has had several of those |
| 12:01 | <JakeA> | Well this is paint rather than layout |
| 12:02 | <annevk> | Ah true, I just group all of those together usually |
| 12:02 | <jgraham> | Right, WR doesn't make layout fast, it makes paint fast. Parellel layout should help with layout |
| 12:02 | <jgraham> | Which ofc Servo already has |
| 12:02 | <jgraham> | It just doesn't have things like correct implementations of Location |
| 12:02 | <jgraham> | Or form controls that don't suck |
| 12:03 | <jgraham> | *parallel |
| 12:03 | <JakeA> | it breaks loads of rendering too, but it's early days |
| 12:04 | <nox> | annevk: Lol @ 80%. |
| 12:04 | <nox> | hgl: 80% + 80% is 100% when you take into account that channel's topic. |
| 12:04 | <JakeA> | My demo is pretty kind to Servo as it uses CSS that it doesn't mess up |
| 12:05 | <hgl> | nox, sorry, still don't quite understand, "that channel's topic"? |
| 12:06 | <nox> | hgl: "#whatwg https://whatwg.org/ — logs: http://krijnhoetmer.nl/irc-logs/ & http://logbot.glob.com.au/ — stats: http://gavinsharp.com/irc/whatwg.html — Please leave your sense of logic at the door, thanks!" |
| 12:06 | <jgraham> | My impression has been that it's relatively better at CSS-derived stuff than at DOM-derived stuff, although there have been shifts in the contributors since I formed that opinion such that it may no longer be the case |
| 12:06 | <hgl> | nox, ok, lol |
| 12:07 | <nox> | jgraham: We have improved many performance bottlenecks in DOM, but there are still many. |
| 12:07 | <jgraham> | nox: Not just performance but missing features |
| 12:07 | <nox> | jgraham: That too. :D |
| 12:07 | <jgraham> | But yeah, I guess it's also true that it doesn't yet have world-beating DOM performance |
| 12:07 | <nox> | jgraham: contentWindow, document.write, NodeIterator, CSSOM… |
| 12:07 | <nox> | MutationObserver. |
| 12:08 | <jgraham> | Well, quite |
| 12:08 | <nox> | Basically every complex part is left as an exercice to the reader. :P |
| 12:08 | <hgl> | a quick question, why no browsers have implemented the nice node.closest() node.query() apis? |
| 12:08 | <nox> | hgl: Because it requires a specific part of CSS selectors 4, |
| 12:08 | <nox> | hgl: namely scoped selectors. |
| 12:10 | <hgl> | nox, i see, thx |
| 12:10 | <nox> | hgl: I started a branch for css4 stuff in rust-selectors, but days are 24 hours long. |
| 12:11 | <hgl> | nox, what about append & prepend ? those don't need selectors 4 i think? |
| 12:12 | <hgl> | nox, you contribute to rust? thank for you hard work.... |
| 12:12 | <nox> | hgl: Servo supports them, that's all I know. :P |
| 12:12 | <nox> | hgl: Servo contributor, starting at Mozilla in two weeks. :) |
| 12:12 | <hgl> | awesome! |
| 12:12 | <nox> | I mostly do DOM stuff and Ms2ger is trying to coerce me into spec editing. |
| 12:13 | <hgl> | wonder if firefox is ever going to replace gecko with servo. :) |
| 12:13 | <nox> | hgl: https://wiki.mozilla.org/Oxidation |
| 12:15 | <ondras> | good naming :) |
| 12:15 | <hgl> | agreed :) |
| 12:15 | <nox> | As long as no one calls that nox, I will be happy. |
| 12:15 | nox | already gets highlighted enough whenever someone mentions some headless Debian package. |
| 13:10 | <JakeA> | annevk: https://github.com/w3c/webcomponents/issues/369#issuecomment-191572976 "That means either sharing the registry with the parent (per the current spec) or just saying that they have no registry" does the latter mean that custom elements wouldn't work in iframes? |
| 13:11 | <annevk> | JakeA: it depends on where you create them |
| 13:15 | <Domenic> | It depends on what they extends actually |
| 13:17 | <Domenic> | class extends iframe.contentWindow.HTMLElement vs. class extends window.HTMLElement |
| 13:18 | <annevk> | Maybe the constructor folk would have put the constructors on document instances |
| 13:18 | <annevk> | new document.HTMLAudioElement() |
| 13:30 | <JakeA> | Could win.defineElement set a symbol on the class setting the default document? |
| 13:31 | <JakeA> | new MyCustomEl() would throw if that symbol wasn't set |
| 13:32 | <nox> | What's wrong with keeping them on the global? |
| 13:32 | <nox> | Shouldn't they rather behave like proper ES classes? |
| 13:33 | <JakeA> | nox: document.createElement know which document to create the elements for |
| 13:33 | <JakeA> | nox: new Whatever() doesn't |
| 13:33 | <nox> | So use document.createElement and don't mess with putting interface objects in the middle of nowhere, no? |
| 13:35 | <nox> | JakeA: I could also just read the thread and shut up. |
| 13:51 | <Domenic> | JakeA: sure, that is one design, is maintaining a global cross-realm mapping table of class instances to documents |
| 13:51 | <Domenic> | I guess we should mention it |
| 14:22 | <annevk> | Cross-realm seems like a bad mismatch with JavaScript |
| 14:32 | <Ms2ger> | annevk, are there plans to pull CSP monkeypatches into HTML? |
| 14:47 | <Ms2ger> | https://github.com/whatwg/html/issues/271 |
| 14:59 | <annevk> | Ms2ger: mkwst usually takes care of that |
| 15:00 | <mkwst> | Yeah. But he's a bit unreliable. |
| 15:00 | <mkwst> | I think there are still a few things missing from HTML and Fetch, but I haven't written them yet. |
| 15:06 | <Ms2ger> | mkwst, fyi, I filed https://github.com/tc39/ecma262/issues/450 |
| 15:07 | <mkwst> | Ms2ger: thank you. |
| 15:14 | <Ms2ger> | Domenic, thanks |
| 15:14 | <Domenic> | Seriously, what a jerk |
| 15:17 | <Ms2ger> | @jspedant |
| 15:17 | <Ms2ger> | Appropriate handle |
| 15:18 | <jgraham> | At risk of being pedantic, it's not, since he was wrong |
| 15:20 | <Ms2ger> | (Also, no way in hell I'm going to subscribe to es-discuss) |
| 15:20 | <Domenic> | literal loling going on here, jgraham |
| 15:36 | <Domenic> | mkwst: what does CSP do to eval and Function? They always throw a TypeError? |
| 15:36 | <Domenic> | If anyone has a test CSP page that'd be helpful. |
| 15:37 | <Domenic> | lol in Firefox it throws an Error |
| 15:37 | <Domenic> | I guess this is entirely underspecified |
| 15:38 | <Domenic> | so I will just let hosts do what they want |
| 15:41 | <Ms2ger> | 154 MSG_DEF(JSMSG_CSP_BLOCKED_EVAL, 0, JSEXN_ERR, "call to eval() blocked by CSP") |
| 15:41 | <Ms2ger> | 155 MSG_DEF(JSMSG_CSP_BLOCKED_FUNCTION, 0, JSEXN_ERR, "call to Function() blocked by CSP") |
| 15:42 | <Ms2ger> | I imagine we'd be willing to change that to a TypeError |
| 15:42 | <Domenic> | I will let the CSP spec define it |
| 15:42 | <Domenic> | Instead of having the hook return true/false and having ES define it's a TypeError |
| 15:43 | <Ms2ger> | wfm either way |
| 15:43 | <Ms2ger> | The latter is closer to what SpiderMonkey does, but eh |
| 15:43 | <mkwst> | Domenic: https://www.w3.org/TR/CSP2/#directive-script-src |
| 15:44 | <Domenic> | mkwst: I was looking at CSP4. |
| 15:44 | <mkwst> | CSP2 waved its hands around the question, and I haven't written the relevant bits of CSP3 yet. |
| 15:44 | <mkwst> | If you have a copy of CSP4, send it over, please. |
| 15:44 | <mkwst> | I'd like to skip a few years of mistakes. :) |
| 15:44 | <Domenic> | lol 3 i guess |
| 15:45 | <Domenic> | mkwst: what should we do if you do someOtherFrame.eval() from within a CSPed frame |
| 15:45 | <mkwst> | 1. Why do people do these things. |
| 15:45 | <Domenic> | to get around CSP I guess :P |
| 15:45 | <mkwst> | 2. We can either take the caller's CSP into account, or the callee's CSP into account. |
| 15:45 | <Domenic> | or both!?! |
| 15:45 | <mkwst> | I don't have strong opinions, but I think I'd lean towards the former. |
| 15:46 | <mkwst> | Or both, I guess. But that sounds like work. |
| 15:46 | <Domenic> | caller sounds simpler |
| 15:46 | <Domenic> | I will pass both to be explicit |
| 15:46 | <Domenic> | That way if CSP explicitly ignores one that's clear |
| 15:46 | <mkwst> | Sounds reasonable. |
| 15:57 | <Ms2ger> | Domenic, fwiw, SM looks at the global of the callee, so I guess that would get around csp |
| 15:57 | <Domenic> | Won't it be good to have this all specified nicely ;) |
| 15:58 | <Ms2ger> | Hoping for a future without COMEFROM :) |
| 15:58 | <Ms2ger> | And thanks for picking it up so quickly |
| 16:00 | <Domenic> | honestly i wouldn't have done so if this guy hadn't been a jerk about it :P |
| 16:01 | <Ms2ger> | :D |
| 16:01 | <annevk> | He wasn't very friendly either about my blacklist/whitelist PR :/ |
| 16:02 | <annevk> | Some people |
| 16:04 | <Domenic> | he's not very friendly in meetings either, by total coincidence |
| 16:37 | <nox> | Domenic: The thread scares me. |
| 16:37 | <Domenic> | nox: which? HTMLAll? |
| 16:37 | <nox> | Domenic: Would be nice for someone to write some summary of it. |
| 16:37 | <nox> | Domenic: Document.all |
| 16:37 | <nox> | I saw "0x0" and it was scary. |
| 16:38 | <Domenic> | yes |
| 16:38 | <Domenic> | great times |
| 16:38 | <Domenic> | i have tried to keep the jsbin and PR updated |
| 16:39 | <nox> | Domenic: I guess we could keep unsigned long or DOMString, |
| 16:39 | <nox> | Domenic: but then we still have to check the string. |
| 16:40 | <nox> | But it could make the TypeScript people happier, I don't know. |
| 16:40 | <Domenic> | nox: that is what we do |
| 16:40 | <Domenic> | in the PR |
| 16:40 | <Domenic> | nox: https://github.com/whatwg/html/pull/780/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR7095 |
| 16:40 | <nox> | Ok so I'm like, very late at the party? |
| 16:40 | <nox> | I saw that but I thought it was still being discussed. |
| 16:40 | <Domenic> | haha ok :P |
| 16:41 | <annevk> | Not sure I'd call document.all a party |
| 16:42 | <Domenic> | nox: is your "Given the binding of WebIDL union types to ECMAScript values:" saying that conversions to strings are performed before conversions to numeric types? |
| 16:42 | <nox> | Domenic: Yes. |
| 16:42 | <jgraham> | It's like a party where the host was already drunk and all the guests have spent the whole night trying to avoid stepping in the vomit |
| 16:42 | <nox> | Domenic: Is that bad? |
| 16:42 | <Domenic> | nox: ok so it's still a good idea to get rid of unsigned long since it's pointless |
| 16:42 | <nox> | Mmh. |
| 16:42 | <nox> | What if I have an arbitrary object, |
| 16:42 | <nox> | that stringifies as "0", |
| 16:43 | <nox> | is that DOMString or unsigned long for the insane current implementations of Document.all? |
| 16:44 | <nox> | Domenic: I'm afraid the TypeScript people are going to complain about document.all(0) not being correctly typed. |
| 16:44 | <Domenic> | nox: they can write their own spec |
| 16:44 | <nox> | Ah ah. |
| 16:44 | <nox> | Domenic: Also, no idea why you would use ugly historical APIs from fancy TypeScript |
| 16:45 | <Domenic> | it seems like Edge has some kind of pipeline where alongside updating IDL files you must also update .d.ts files that they ship with Visual Studio or something |
| 16:46 | <nox> | Domenic: Sorry, you misunderstood me. |
| 16:46 | <nox> | Domenic: My quote was only about string values. |
| 16:46 | <nox> | Let me put the step just before in a new comment. |
| 16:48 | <Domenic> | nox: oh I see |
| 16:48 | <Domenic> | so the step is still kind of pointless since it's normatively the same to just treat everything as a string, but at least it's not dead code |
| 16:49 | <Domenic> | well it's maybe not the same |
| 16:49 | <Domenic> | { toString() { return "42"; } valueOf() { return 43; } } |
| 16:49 | <nox> | Domenic: Ugh. :( |
| 16:52 | <nox> | Domenic: Are you sure it's not 42 with the current code? |
| 16:53 | <Domenic> | nox: oh you're right |
| 16:53 | <nox> | Domenic: And it would be the same with just DOMString AFAICT. |
| 16:54 | <nox> | Domenic: I have no idea what browsers do though anyway. |
| 16:57 | <nox> | Domenic: document.all(({ 'toString': function () { return "1"; }, 'valueOf': function () { return 0; } })) returns <head> in Safari. |
| 16:58 | <Domenic> | good! |
| 17:00 | <nox> | Anyway, Real Life is calling, see you later maybe. |
| 17:00 | <Domenic> | i remember real life... |
| 17:00 | <Domenic> | before my life was consumed by document.all |
| 17:01 | <Ms2ger> | Likewise |
| 17:23 | <annevk> | Domenic: do we want https://www.w3.org/Bugs/Public/show_bug.cgi?id=28566 still? |
| 17:23 | <Domenic> | annevk: yes, I think authors would really appreciate it |
| 17:24 | <Domenic> | at least, as long as implementers think it's OK |
| 17:24 | <annevk> | clone = global.structuredClone(value, transfer = []) |
| 17:24 | <annevk> | or do we also want to expose the transferList? Hmm |
| 17:24 | <Domenic> | Yeah |
| 17:25 | <Domenic> | We could move it to GitHub and ask authors for use cases + browser vendors for "will you implement this" |
| 17:25 | <annevk> | Will do once I figure out what the return value should be |
| 17:27 | <annevk> | Okay, we don't need [[TransferList]] since that is only for ports and those are only useful if you actually go elsewhere with this |
| 17:53 | <annevk> | Does anyone else get "You signed in with another tab or window. Reload to refresh your session." a lot on GitHub? |
| 17:53 | <annevk> | Why can't they just make it work |
| 17:58 | <miketaylr> | annevk: i don't think i've seen that one :/ |
| 17:58 | <nox> | Domenic: Please double check that 2^32 value, we never know. :P |
| 17:58 | <miketaylr> | i know karl gets strange github errors i've never seen (from japan) |
| 18:17 | <JakeA> | annevk: Domenic: once the custom element constructor thing is solved, does that enable new HTMLDivElement() etc? |
| 18:18 | <annevk> | JakeA: we could have HTMLDivElement() if we wanted to |
| 18:18 | <annevk> | JakeA: it might be slightly better if we first decide if there are any required arguments I suppose, but I don't think there should be |
| 18:19 | <JakeA> | annevk: I thought there were different elements that share the same constructor, but can't remember what they were |
| 18:19 | <JakeA> | If there are some, maybe tag name is an optional arg |
| 18:20 | <annevk> | JakeA: ah yes, I think we should stop that, if we can |
| 18:20 | <annevk> | JakeA: just give each element a class |
| 18:20 | <JakeA> | yeah, that's a better solution |
| 18:20 | <annevk> | I'm a little worried about compat, but hopefully it's fine |
| 18:20 | <annevk> | This hasn't really come up lately since nobody has been asking about it |
| 18:21 | <annevk> | I've also wondered what happened to your promise state proposal, of adding that to most things |
| 18:23 | <JakeA> | ohhh the .ready stuff? Yeah, that would be nice too. If I run into some more time I should do a PR |
| 18:28 | <annevk> | JakeA: yeah, would love that |
| 18:47 | <miketaylr> | has anyone in the "remove appCache" camp thought about what happens to code calling methods or props on window.applicationCache? |
| 18:48 | <miketaylr> | (https://bugzilla.mozilla.org/show_bug.cgi?id=1252860#c1) |
| 19:01 | <annevk> | miketaylr: not really |
| 19:02 | <miketaylr> | annevk: only one way to find out... |
| 19:03 | <annevk> | miketaylr: could make them all no-op |
| 19:03 | <annevk> | miketaylr: if problematic |
| 19:03 | <miketaylr> | window.applicationCache.toString() == [object DoucheBag] |
| 19:03 | <miketaylr> | annevk: yeah, i'll keep investigating to see how big a problem it will be |
| 19:04 | <annevk> | heh |
| 19:54 | <danbeam> | does anybody know if PromiseResolver removed from https://dom.spec.whatwg.org/? https://developer.mozilla.org/en-US/docs/Web/API/PromiseResolver links to https://dom.spec.whatwg.org/#promiseresolver but that <a name> no longer exists (nor is "PromiseResolver" in that document) |
| 19:54 | <danbeam> | if PromiseResolver was removed from* |
| 19:55 | <danbeam> | annevk: ^ |
| 19:56 | <annevk> | danbeam: promises are defined in ECMAScript these days |
| 19:56 | <danbeam> | annevk: ok, will poke around there |
| 19:56 | <danbeam> | annevk: thx |
| 19:56 | <annevk> | danbeam: that page can prolly be removed |
| 19:57 | <danbeam> | annevk: yeah, was wondering who to bother about that |
| 19:57 | <danbeam> | annevk: i suppose i can do it myself and see if I have access / who screams |
| 19:57 | <annevk> | danbeam: yeah, teoli is my goto MDN contact |
| 19:58 | <annevk> | danbeam: but with wikis you can just go ahead and answer questions later 😀 |
| 19:59 | <danbeam> | annevk: in trying to edit i've struck out 3 times with github oauth / persona, requires authentication at least |
| 19:59 | <danbeam> | teoli is a previous editor |
| 20:02 | <annevk> | danbeam: aww bummer, cannot help with that, ask on #mdn on Moziila IRC |
| 20:58 | <annevk> | Domenic: can't believe I didn't think of it before, but we should do s/IDL-defined object/Platform object/ |
| 20:58 | <annevk> | Domenic: maybe tomorrow |
| 21:04 | <zcorpan> | Domenic: document.all(4294967296) // looks up the element at index 0 - does this match any browser? |
| 21:09 | <zcorpan> | i might actually start to use document.all(0) instead of document.documentElement, i always manage to make a typo in the latter :-) |
| 21:20 | <rniwa> | Domenic: hi |
| 21:20 | <Domenic> | rniwa: hi |
| 21:21 | <rniwa> | Domenic: so it turns out that sharing registry with window-less documents won't work |
| 21:21 | <rniwa> | Domenic: Because even in that case, HTMLElement constructor can't figure out to which document it belongs |
| 21:22 | <rniwa> | Domenic: so you end up creating a document in window.document |
| 21:22 | <Domenic> | rniwa: it just looks up the HTMLElement constructor's window's active document |
| 21:22 | <rniwa> | Domenic: and adopting it |
| 21:23 | <Domenic> | which if the registry is shared, will have all the same entries as the createElement() ones |
| 21:23 | <Domenic> | *createDocument() |
| 21:24 | <rniwa> | Domenic: but then ownerDocument will be wrong initially and it would be observable in the custom element's constructor |
| 21:25 | <Domenic> | Ah I see |
| 21:25 | <Domenic> | ownerDocument as the problem, not just the registry |
| 21:26 | <rniwa> | Domenic: since I really don't want to punish the common case by forcing authors to specify document |
| 21:26 | <Domenic> | Just disallow it in documents without associated windows? |
| 21:26 | <rniwa> | Domenic: and you guys don't want to make document optional |
| 21:26 | <rniwa> | Domenic: we just need to disallow in window-less documents |
| 21:26 | <Domenic> | sounds good to me |
| 21:27 | <Domenic> | thanks for discovering all the edge cases first |
| 21:28 | <rniwa> | Domenic: nope, I had to talk with my colleagues about this anyway |
| 21:52 | <rniwa> | Domenic: a WebKit patch is forthcoming ;) https://bugs.webkit.org/show_bug.cgi?id=154944 |
| 22:17 | <peterjoel> | hi, I submitted a PR to some tests on DOMMatrix, but the build failed in a way that looks like it needs to just be retried |
| 22:17 | <peterjoel> | https://github.com/w3c/csswg-test/pull/1060 |
| 22:17 | <peterjoel> | https://travis-ci.org/w3c/csswg-test/builds/113513577#L318 |
| 22:17 | <peterjoel> | “No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.” |
| 22:22 | <peterjoel> | Also, I need to create new tests for DOMMatrix and DOMMatrixReadOnly. Shall I just make PRs? |