| 00:01 | <MikeSmith> | bterlson: yeah it's wattsi and regarding the speed, as Domenic pointed out it doesn't attempt to provide a general-purpose DOM and it's all AOT; and on top of that, I think Hixie coded it carefully for very high performance, and the FreePascal fpc compiler itself apparently has some pretty nice optimization tricks and overall Hixie took good advantage of some of the smarter features the language+compiler |
| 00:01 | <MikeSmith> | provide |
| 00:03 | <MikeSmith> | bterlson: as far as what source --> output generation tasks it's doing, it's the same as Bikeshed or other (previous) spec-gen tools, plus probably a little more for some more arcane things that are specific to the HTML spec source and not just general |
| 00:03 | <MikeSmith> | see https://github.com/whatwg/wattsi#features but that's not a complete list I think |
| 00:05 | <MikeSmith> | Number the sections · Create Table of Contents · Cross-reference <span> and <code> to <dfn> · Create small TOC · Cross-reference back (<dfn> menu) · Strip out unused references · Spec splitting |
| 00:13 | <MikeSmith> | Domenic: bterlson btw I wonder if y’all have put consideration yet into doing a mult-page version of the ES spec |
| 00:15 | <MikeSmith> | I don't know how big the output ES spec is at that point, but back when I did https://es5.github.io/ I remember it being big enough that it was useful to have a multi-page version https://es5.github.io/multi.html |
| 00:15 | <bterlson> | MikeSmith: under consideration (it'd be trivial for emu to emit a multi-page spec). But everyone around here prefers the full spec. |
| 00:16 | <bterlson> | arguably with my nifty search box, multi-page becomes much easier as search isn't broken |
| 00:21 | <MikeSmith> | ok |
| 00:22 | <MikeSmith> | well in some places people on slower connections might like having a smaller document to have to load |
| 00:22 | <MikeSmith> | and I am pretty sure there are enough crazy other people like me who also attempt to read specs on smartphones |
| 00:23 | <MikeSmith> | in which case scrolling and some other things are a bit less pleasant with big single documents |
| 00:25 | <MikeSmith> | Domenic: I'm noticing/recalling that the HTML spec dfn popup thing doesn't work cross-file in the multipage output |
| 00:25 | <MikeSmith> | can't remember if we have an issue open for that |
| 00:25 | MikeSmith | checks |
| 00:26 | <Domenic> | MikeSmith: we definitely do |
| 00:26 | <Domenic> | It's a high work, high reward wattsi task |
| 00:26 | <Domenic> | You have to generate the pop-ups ahead of time |
| 00:27 | <Domenic> | bterlson: I prefer multipage specs for other specs to link to |
| 00:27 | <Domenic> | I hate clicking a link and hanging Firefox for ten minutes |
| 00:28 | <bterlson> | Firefox needs to fix their ecma262 rendering speed, it's the worst of the bunch |
| 00:28 | <Domenic> | While implementing or speccing, singlepage is great |
| 00:28 | <Domenic> | Yeah Firefox is not good at large documents |
| 00:28 | <bterlson> | chrome loads on my crappy laptop in 2 seconds or so. |
| 00:28 | <bterlson> | seems fine ;) |
| 00:29 | <bterlson> | so we got a chakra dev that uses chrome, a chrome dev that uses firefox, all we need to find is a firefox dev that uses edge and the circle is complete |
| 00:29 | <Domenic> | Except, nobody but us uses Windows, waaaa waaaaaaa |
| 00:37 | <bterlson> | Domenic: Not since you moved off :( |
| 00:38 | <MikeSmith> | haha |
| 00:38 | <MikeSmith> | A chakra dev that uses chrome, a chrome dev that uses firefox, and a firefox dev that uses edge walk into a bar... |
| 00:40 | <Domenic> | bterlson: that's just my Google laptop, still rocking two Windows desktops and a Surface Pro 4 :D |
| 00:45 | <bterlson> | I just got the SP4 myself for home |
| 00:46 | <bterlson> | pretty nice machine except my pen stops working sometimes :( |
| 00:48 | <Domenic> | I used the pen once |
| 00:48 | <Domenic> | It was kind of cool |
| 00:49 | <Domenic> | I'm still angry they haven't fixed the bug where you lock your screen sideways then plug in a keyboard and your screen stays locked sideways and can't be unlocked until you unplug the keyboard |
| 00:50 | <bterlson> | Domenic: get the NYT crossword app |
| 00:50 | <bterlson> | pen makes crosswords on computer actually fun |
| 02:46 | <roc> | Domenic: you mean this? http://www.ecma-international.org/ecma-262/6.0/index.html loads in Firefox in a few seconds for me |
| 04:18 | <MikeSmith> | roc: I think instead https://tc39.github.io/ecma262/ (though that also loads quickly for me in Firefox) |
| 04:19 | <roc> | yeah, that loads even faster for me :-) |
| 04:40 | <annevk> | Domenic: I noticed yesterday that Streams has some <emu-alg> and <emu-val> in the output, bug? |
| 05:12 | <annevk> | Domenic: the weird thing is that sometimes <emu-val> is used and sometimes <b> |
| 05:12 | <Domenic> | annevk: nah, feature |
| 05:12 | <Domenic> | annevk: emu-val should be used for all ecmascript values, hmm |
| 05:13 | <annevk> | Domenic: maybe it's just some legacy <b> stuff |
| 05:13 | <Domenic> | roc: it loads in 2s ish, but locks up the entire browser while doing so |
| 05:14 | <Domenic> | annevk: ah I see, the stuff I authored by hand uses <b>, the stuff output uses <emu-val>. Yeah those should be <emu-val>s... |
| 05:14 | <annevk> | I was looking yesterday for what I wanted to use for HTML |
| 05:14 | <annevk> | I was thinking just <b> for now |
| 05:15 | <Domenic> | yeah |
| 05:15 | <Domenic> | HTML is weird because it doesn't bold the stuff ES bolds |
| 05:15 | <Domenic> | like null |
| 05:15 | <Domenic> | and I think true and false too |
| 05:15 | <annevk> | Also, my plan is to just have a big fat warning about Window not being able to become exotic and explain the whole thing, since it's not observable |
| 05:15 | <Domenic> | :( :( :( |
| 05:16 | <annevk> | Yeah, I'm not sure how the two styles will go together |
| 05:16 | <Domenic> | I am sad that the proxy is not acting as a proxy, and am sad that CrossOriginX() will actually do both cross origin and same origin behavior. |
| 05:16 | <annevk> | I'm hoping that once we get to refactoring IDL we'll be able to set some kind of algorithm styleguide |
| 05:16 | <annevk> | Had not considered that second concern |
| 05:17 | <annevk> | Though again, that would bring us back to that Helper abstract operation |
| 05:17 | <annevk> | Meh |
| 05:34 | <MikeSmith> | Domenic: philipj about those lint greps, one minor refinement to consider is that we catch-fire-and-fail on the first one |
| 05:34 | <MikeSmith> | stop and don't bother to check any further if we find a problem |
| 05:35 | <MikeSmith> | in the normal (no errors) case it doesn't make anything faster of course, so maybe there's no point |
| 05:48 | <annevk> | Being able to PR ECMAScript is so nice |
| 06:31 | <annevk> | Many +s to philipj for filing all ideas as issues |
| 06:42 | <philipj> | MikeSmith: I guess you're tempted because that makes it easier to return 1 on failure? :P |
| 06:42 | <philipj> | MikeSmith: which would be fine I guess, it just wouldn't speed up successful builds |
| 06:50 | <philipj> | annevk: https://github.com/whatwg/html/issues/620#issuecomment-180218755 looks promising |
| 07:36 | <annevk> | MikeSmith: would be more annoying if you are on the end of having to fix those errors |
| 07:48 | <MikeSmith> | ok I'll just have it continue |
| 08:20 | <ritsyy> | should this bug be closed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28709 , is it mentioned somewhere that the panel could be closed with the upper right corner handle or should it be? |
| 08:35 | <philipj> | ritsyy: yeah, it seems to work for me |
| 08:36 | <philipj> | ritsyy: will comment on bug |
| 09:46 | <annevk> | wanderview: https://github.com/whatwg/fetch/pull/200/files#r51456507 |
| 09:47 | <annevk> | JakeA: what's the conclusion on https://github.com/whatwg/fetch/pull/194? Shall I merge it and open some issues? |
| 09:52 | <annevk> | Minor announcement: I deleted the "html team" from GitHub, but everyone is still part of the repository |
| 09:54 | <JakeA> | annevk: yeah I'm happy with it apart from what I already commented |
| 09:55 | <annevk> | JakeA: yeah, but you commented on the text in the current draft mostly, not on the refactoring |
| 09:55 | <annevk> | that made it a little hard to figure out what I should be doing |
| 09:58 | <JakeA> | annevk: huh, I though the "HTTP redirect fetch" section was what we were reviewing? |
| 09:58 | <annevk> | JakeA: all that text already exists, this is just that text in its own section so it can be reused by HTML's navigate |
| 09:59 | <annevk> | JakeA: but it's great to have it reviewed too |
| 10:01 | <JakeA> | annevk: I reviewed it from the point of view of navigate calling out to it, but also a normal "follow" redirect. Seems fine. Might want tweaks following the resolution of the base uri thing. |
| 10:03 | <annevk> | JakeA: well, https://github.com/whatwg/fetch/pull/194#discussion_r51465810 will need tweaking either way, that's a serious issue |
| 10:03 | <JakeA> | Agreed |
| 10:04 | <annevk> | JakeA: see also https://github.com/whatwg/html/issues/613 btw, everything sorta uses the response URL for base these days, but the initial request URL |
| 10:05 | <annevk> | JakeA: we forgot about module scripts having subresources in the same way that CSS does |
| 10:05 | <JakeA> | annevk: I didn't realise they had their own base |
| 10:06 | <annevk> | only for the static bits |
| 10:06 | <JakeA> | annevk: as in the imports? |
| 10:06 | <annevk> | yeah |
| 10:10 | <JakeA> | annevk: as I'm coming around to using response URL as base everywhere, most developers are saying request URL is intuitive :( |
| 10:11 | <JakeA> | That would break CSS redirects from the SW of course, which I'm not keen on |
| 10:14 | <annevk> | https://github.com/whatwg/fetch/issues/212 |
| 10:14 | <annevk> | And module script redirects |
| 10:15 | <annevk> | And URLs in workers |
| 10:16 | <annevk> | Did we consider workers? Today if I do new Worker("/x") and the server redirects to /bar/x and all the links inside the worker are relative, that works |
| 10:16 | <annevk> | Once you use a service worker that eats the redirects, all those links would break |
| 10:20 | <JakeA> | Agreed. And although I think of pages differently because of URL bar visibility, I guess I'll get over it :D |
| 10:33 | <tobie> | If I have an interface attribute of type Foo, can it hold a value of type FooChild if FooChild inherits from Foo? |
| 10:35 | <annevk> | Yes |
| 10:36 | <annevk> | See: all of DOM |
| 10:36 | <tobie> | Yeah, I assumed that was the case, didn't really know where to look for confirmation in the spec. |
| 10:37 | <tobie> | annevk: thanks, btw :) |
| 10:38 | <ritsyy> | philipj: there is one more bug related to the user-interface https://www.w3.org/Bugs/Public/show_bug.cgi?id=28829 |
| 10:39 | <tobie> | annevk: is there a place in the spec where that's explicit? |
| 10:39 | <annevk> | tobie: must be in IDL somewhere |
| 10:39 | <tobie> | :D |
| 10:41 | <annevk> | tobie: in https://heycam.github.io/webidl/#idl-interfaces I guess, but I can't find it quickly |
| 10:41 | <Ms2ger> | "An identifier that identifies an interface is used to refer to a type that corresponds to the set of all possible non-null references to objects that implement that interface." |
| 10:42 | <tobie> | Ms2ger: Thank you. I could have read this 10 times without figuring it was the answer to my question. |
| 10:42 | <Ms2ger> | :D |
| 10:42 | <ritsyy> | philipj: i didn't get that what would be the possible solution for https://www.w3.org/Bugs/Public/show_bug.cgi?id=28709 as you mentioned in the comment should the UI be altered for this? |
| 10:43 | <tobie> | annevk: thanks again (didn't mean to make you peruse the WebIDL spec, btw; apologies) |
| 10:46 | <annevk> | heh, no worries |
| 10:55 | <Ms2ger> | philipj, I disclaim all knowledge about menuitem, try wchen :) |
| 11:41 | <ritsyy> | annevk: in this https://www.w3.org/Bugs/Public/show_bug.cgi?id=27274 should those event handlers(beforecopy event and more) be added , am i getting it right? |
| 12:44 | <jochen__> | about https://github.com/whatwg/html/issues/632 |
| 12:44 | <jochen__> | anybody has a good definition to offer for "browsing context responsible for starting the navigation"? |
| 12:55 | <annevk> | ritsyy: sorry, got distracted |
| 12:56 | <annevk> | ritsyy: I think we might end up removing the before* events mentioned there so those should probably not be added |
| 14:03 | <ritsyy> | annevk: sorry was afk, then adding onpaste in the list seems fine? |
| 14:03 | <annevk> | yeah |
| 14:04 | <annevk> | ritsyy: also oncut/oncopy |
| 14:05 | <annevk> | ritsyy: and only to elements per Hixie_'s comment there |
| 14:05 | <ritsyy> | annevk: ok yeah, got that |
| 14:57 | <wanderview> | annevk: JakeA: since I suck and never reviewed the PR... can either of you summarize any functional changes to manual redirects from this? https://github.com/whatwg/fetch/pull/194 |
| 14:57 | <wanderview> | or should it work the same way, but with just different spec language |
| 14:57 | wanderview | sucks at reading html diffs. |
| 14:58 | <JakeA> | I think the idea is for it to work the same way |
| 14:59 | <JakeA> | wanderview: I cloned the repo, switch to the pr branch & read in a browser |
| 14:59 | <JakeA> | I only used the diff to work out which sections were new |
| 15:00 | <wanderview> | yea... that works I guess |
| 15:00 | <wanderview> | thanks for the clarification the function probably shouldn't change |
| 15:00 | <annevk> | wanderview: basically we return early now for manual redirects |
| 15:01 | <wanderview> | not writing a gecko bug to update for new behavior |
| 15:01 | <annevk> | wanderview: rather than do some checks before |
| 15:01 | <wanderview> | we don't implement manual redirects exactly like fetch spec anymore anyway |
| 15:01 | <annevk> | is that something we won't fix? |
| 15:02 | <wanderview> | we fixed it not to be special case for fetch() any more... its now done down in the nsIChannel |
| 15:03 | <wanderview> | which we needed in order to properly allow manual redirects to work without triggering failures when redirect from https-to-http |
| 15:15 | <JakeA> | Domenic: You're a JS expert, help settle a bet (if you've got time). In ye olde es5 days a for loop could be transformed into a while loop pretty easily http://jsbin.com/suyuqi/edit?js, but that isn't possible anymore, right? |
| 15:17 | <ondras> | JakeA: shouldn't the "if (C){}" line be "C;" instead? |
| 15:17 | <JakeA> | ondras: no, it needs to throw if C isn't a simple expression, the 'if' enforces that |
| 15:18 | <JakeA> | for (;false;var foo = 'bar') throws |
| 15:18 | <JakeA> | well, it's a syntax error |
| 15:19 | <ondras> | I see. |
| 15:23 | <annevk> | Domenic: typing out the whole cross-origin objects thing is taking longer than expected |
| 16:05 | <JonathanNeal> | Thanks alrra . |
| 16:43 | <JakeA> | Domenic: this is as far as we got trying to represent a for loop as a while http://jsbin.com/labezor/edit?js,console |
| 16:46 | <Domenic> | JakeA: I'm... really not sure why you're trying to do this? |
| 16:47 | <JakeA> | Domenic: the goal is to understand how for() works in terms of its scoping |
| 16:47 | <JakeA> | Babel gets it wrong, so we're trying to figure out what's right |
| 18:12 | <nikkibee> | what does it mean for the request redirect mode to be `manual`? https://fetch.spec.whatwg.org/#concept-request-redirect-mode |
| 18:13 | <nikkibee> | I ask because of step 10, on a redirect status, under step 5 of http fetch https://fetch.spec.whatwg.org/#http-fetch |
| 18:14 | <nikkibee> | my assumption is that a redirect mode is set to `manual` meaning, the user clicked on something themselves? should that be so, I don't know how I could recreate this inside a test case |
| 20:17 | <miketaylr> | rbyers: will dig thru old bugs and reply to that thread in a bit (just finishing up some stuff right now) |
| 20:17 | <nikkibee> | nvm on what I was asking earlier, I realized I actually just need to set the redirect mode when I'm making the request- not in the middle of the fetch function |
| 20:19 | <rbyers> | miketaylr: Ok, no rush (but I'm on vacation starting in 2 hours <grin>). I'm just trying to figure out where this change lies on the spectrum of wishful thinking but not really practical for advancing the web and really valuable to push the last remaining sites (including GMail) off of. |
| 20:20 | <miketaylr> | heh |
| 20:21 | <miketaylr> | i get the hunch we saw this quite a bit in japanese sites, but need to hunt down a spreadsheet |
| 20:21 | <miketaylr> | you know, the best place to keep a record of bugs >_> |
| 20:28 | <annevk> | nikkibee: fetch() can set the redirect mode |
| 20:28 | <nikkibee> | annevk: do you mean the javascript api? |
| 20:28 | <annevk> | nikkibee: you can also observe it in service workers for navigation (manual) |
| 20:28 | <annevk> | nikkibee: yup |
| 20:29 | <nikkibee> | annevk: heh, I got the idea about what was wrong in my logic when somebody linked me the part of the JS api that sets redirect mode |
| 20:29 | <nikkibee> | I don't deal with JS or the fetch JS api at all |