| 00:21 | <Domenic> | tobie: they're shims for most everything.... streams, buffer (their alternative to typed arrays), etc. |
| 00:45 | <heycam> | mounir: hey. I'm busy this week but will look at it next week, if that's ok. |
| 08:21 | <annevk> | ritsyy (and everyone else): make sure to update whatwg/html-build |
| 08:22 | <annevk> | we landed some changes that require updating it |
| 08:30 | <ritsyy> | annevk: okay, ta |
| 08:30 | <annevk> | ritsyy: maybe also wattsi |
| 08:31 | <annevk> | ritsyy: the upshot is that everything should go a little faster |
| 08:33 | <ritsyy> | annevk: okay, is the script updated to work offline? |
| 08:38 | <annevk> | ritsyy: still requires two downloads if you don't set -n, but they are relatively small |
| 08:39 | <ritsyy> | annevk: oh okay, great! |
| 09:55 | <skender> | how make a fetch post request with content-type json/application? when i put json.stringify(json) in the body, the content-type is set to text/plain.. |
| 10:38 | <Ms2ger> | hallvors, ping |
| 10:39 | <hallvors> | Ms2ger: here :) |
| 10:40 | <Ms2ger> | hallvors, do you know if there's a test that readystatechange is dispatched sync from xhr.open()? |
| 10:41 | <hallvors> | Hm.. I'll look. I think so but can't say for sure |
| 10:43 | <hallvors> | Ms2ger: I guess https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/open-open-sync-send.htm might do? |
| 10:44 | <Ms2ger> | Seems like it does, yes |
| 10:44 | <Ms2ger> | Thanks :) |
| 10:45 | <hallvors> | it's not explictly about that (it's a bit weirder) but covers it |
| 10:45 | <hallvors> | perhaps we should have an explicit non-weird test too .. |
| 10:45 | <annevk> | it doesn't cover the synchronous bit though |
| 10:45 | <annevk> | it just checks that a transition happened, not when |
| 10:46 | <Ms2ger> | But it does that check before the event loop spins |
| 10:46 | <annevk> | I think I had written some tests where I also added logging before and after the open call |
| 10:46 | <Ms2ger> | But something more explicit would of course be nice :) |
| 10:47 | <Ms2ger> | Oh wait, I guess the xhr might spin the event loop |
| 10:47 | <hallvors> | we can always add a couple more asserts to that test.. |
| 10:47 | <annevk> | Ms2ger: not per spec |
| 10:47 | <hallvors> | like one before send() |
| 10:48 | <hallvors> | I also think we have some that do more detailed logging, just need to find them.. |
| 10:48 | <Ms2ger> | (I haven't found any bugs here, btw, but it seems like something worth testing) |
| 11:11 | <hallvors> | annevk, Ms2ger: I'll just add a specific test.. |
| 11:11 | <Ms2ger> | Thanks |
| 11:23 | <Ms2ger> | Do we not yet have a better way to write "If parsing mime analogously to the value of the `Content-Type` header fails..."? |
| 11:27 | <hallvors> | Ms2ger: https://critic.hoppipolla.co.uk/r/6166 |
| 11:28 | <Ms2ger> | Thanks, will look in a bit |
| 11:28 | <hallvors> | Pardon the mess with the first PR being mistakenly branched off a branch full of clipboard stuff.. |
| 11:28 | hallvors | wishes those clipboard tests get merged soon.. |
| 11:29 | hallvors | wants git to ask "are you sure" when doing checkout -b newbranch and not on master |
| 11:30 | <hallvors> | no haste, but also a veeeery simple review, won't take you long ;) |
| 11:39 | <Ms2ger> | hallvors, reviewed, and want one more test :) |
| 11:39 | <Ms2ger> | Now, lunch |
| 11:39 | <hallvors> | your wish is my command, Sir :) |
| 12:14 | <Ms2ger> | hallvors, I probably would have stuck it in the same file, but eh :) |
| 12:16 | <Ms2ger> | hallvors, I also want all the XHR tests to run in workers too :) |
| 12:16 | <hallvors> | hm.. most of them don't, seems like a bit of work to fix that.. |
| 12:17 | <hallvors> | :/ |
| 12:17 | <Ms2ger> | Yeah |
| 12:18 | <Ms2ger> | I really want a fix for https://github.com/w3c/web-platform-tests/issues/2558 |
| 12:21 | <hallvors> | Ms2ger: wouldn't be that much work if we wrote a script that would extract all the code from the XHR tests into .js files |
| 12:22 | <Ms2ger> | The one thing we'd lose is the spec links, I guess |
| 12:22 | <Ms2ger> | Though that seems fixable |
| 12:23 | <jgraham> | Ms2ger: Presumably you could do the same as the .worker.js files but with a .global.js or something with something to tell the test what context it is running in (a boolean doesn't seem ideal) |
| 12:23 | <Ms2ger> | Yeah, agreed |
| 12:23 | <Ms2ger> | Then the question is what to do with shared/service workers |
| 12:23 | <Ms2ger> | Maybe if (type === "service worker") return |
| 12:25 | <jgraham> | Or have some mechanism to define what kind of tests should be run |
| 12:25 | <jgraham> | Like |
| 12:25 | <jgraham> | //test contexts(worker, window) |
| 12:25 | <jgraham> | and run a regexp in the manifest parser |
| 12:26 | <Ms2ger> | That seems like the least wasteful approach |
| 12:32 | hallvors | wants the spec links and the xpaths preserved.. |
| 12:56 | <hallvors> | Here's another one for you, Ms2ger :) https://github.com/w3c/web-platform-tests/pull/2563 |
| 12:57 | <Ms2ger> | Woo, <details> landed in Gecko |
| 13:00 | <Domenic> | \o/!!! |
| 13:00 | <Domenic> | just when i was thinking esprehn had me convinced to remove it from the spec |
| 13:02 | <annevk> | Domenic: I don't understand https://github.com/annevk/html-cross-origin-objects/issues/32 |
| 13:02 | <annevk> | Domenic: I think you're making some assumptions that might be false |
| 13:04 | <annevk> | Domenic: while you are correct that Location is exotic and Window will not be, the behavior implemented by Location and Window*Proxy* will be nearly identical |
| 13:06 | <annevk> | Domenic: I'd much rather have an answer to https://github.com/annevk/html-cross-origin-objects/issues/32#issuecomment-179817893 |
| 13:06 | <annevk> | Domenic: other than that the specification works as-is, afaict |
| 13:07 | <Domenic> | annevk: if the behavior implemented will be nearly identical, then I think the spec needs to be a lot more identical |
| 13:07 | <annevk> | Domenic: that is why they all use shared abstract operations |
| 13:08 | <Domenic> | annevk: they shouldn't, since WIndowProxy needs to delegate to its target, instead of calling defaultinternalmethod. That is my answer to the linked comment. |
| 13:08 | <Domenic> | ("In general I think CrossOriginGetOwnProperty should probably be removed in favor of explicit different algorithms for each of the two objects.") |
| 13:08 | <Domenic> | If you want them to be identical then you should make Location a proxy too |
| 13:08 | <annevk> | Domenic: why can't they use shared abstract operations that operate on different objects? |
| 13:08 | <annevk> | Domenic: show me how that fails |
| 13:09 | <Domenic> | annevk: it doesn't fail right now, assuming you redefine window named properties. It's just bad software engineering practice to rely on the internal implementation details of the object you're proxying |
| 13:09 | <annevk> | Domenic: this is part of the definition of that object though |
| 13:09 | <Domenic> | annevk: WindowProxy should be a proxy. So it should delegate to its target. I'm not sure how to make that any clearer. |
| 13:09 | <annevk> | Domenic: this is kind of the whole point |
| 13:10 | <annevk> | Domenic: that we know about the details of Window and can therefore do things on WindowProxy |
| 13:10 | <annevk> | to make them work well together |
| 13:10 | <Domenic> | How is that the whole point? They should be layered, not intertwingled. |
| 13:10 | <annevk> | they are intertwingled in impls too |
| 13:10 | <Domenic> | that's not true in chrome |
| 13:11 | <Domenic> | and I doubt that bz would use this kind of defaultinternalmethod stuff, but we can ask him |
| 13:11 | <Domenic> | This is not a hard change to make |
| 13:11 | <annevk> | oh, I want to reply DefaultInternalMethod with Ordinary* |
| 13:11 | <Domenic> | I am unclear why you are pushing back on it |
| 13:11 | <Domenic> | sure whatever |
| 13:11 | <Domenic> | same bad practice, different name |
| 13:11 | <annevk> | I don't understand what change you are proposing |
| 13:11 | <annevk> | It sounds like you want to duplicate all these abstract operations |
| 13:11 | <annevk> | While they do exactly the same |
| 13:11 | <Domenic> | use W.[[GetOwnProperty]](...), not OrdinaryGetOwnProperty(W, ...) |
| 13:11 | <Domenic> | that is the important higher-order bit |
| 13:13 | <annevk> | Yeah, that would require duplicating all the text with much more chance for divergence |
| 13:13 | <Domenic> | I can't think of an easy way to do that without either: (a) creating separate algorithms for window and location, or (b) making Location a proxy too. |
| 13:13 | <annevk> | That seems extremely silly |
| 13:14 | <Domenic> | but I think it will match impls better, be more maintainable longer-run due to the decoupling, and either be clearer about the fact that both are proxies, or be clearer about the fact that both are very different types of objects |
| 13:14 | <annevk> | Given that this is all legacy and we'll never make these objects even worse I doubt any of that is really true |
| 13:15 | <Domenic> | OK I think I found a (c) |
| 13:15 | <annevk> | The main problem that gives us that reviewing will be much harder |
| 13:15 | <Domenic> | Instead of step 1 of CrossOriginX(...) being "if is same origin, use defaultinternalmethod" |
| 13:15 | <annevk> | To ensure that the security properties are indeed identical |
| 13:15 | <Domenic> | move that step into the caller |
| 13:15 | <Domenic> | and leave CrossOriginX(...) to be only for the cross origin case |
| 13:16 | <Domenic> | then that step can use either DefaultInternalMethod for Location, or delegation for WindowProxy |
| 13:16 | <Domenic> | There, that's pretty easy. |
| 13:17 | <annevk> | I still don't really see what that buys us. If we ever change Window to be exotic we could do this rewrite then |
| 13:17 | <annevk> | In any event, that doesn't solve https://github.com/annevk/html-cross-origin-objects/issues/32#issuecomment-179817893 |
| 13:17 | <Domenic> | Remembering that we have to is a problem. |
| 13:17 | <Ms2ger> | zcorpan, https://github.com/w3c/web-platform-tests/pull/2513 |
| 13:18 | <annevk> | I don't think so |
| 13:18 | <annevk> | I mean, I don't think we ever want to make platform objects more exotic and if we did we'd have to review it for Window/Location carefully anyway |
| 13:18 | <Domenic> | Re https://github.com/annevk/html-cross-origin-objects/issues/32#issuecomment-179817893 I think in general the CrossOriginXs should not branch on their input, so I guess the "remove step 4" thing |
| 13:19 | <annevk> | Domenic: if an abstract operation doesn't return anything, is the return value undefined? |
| 13:19 | <Domenic> | It's just ... gah ... I can't really explain this as anything more than best practices. Proxies should act like an actual proxy, and be decoupled from internal knowledge of their target. |
| 13:19 | <Domenic> | annevk: I'll check, not sure |
| 13:20 | <annevk> | Domenic: is there a way to pass the correct thing to call into the CrossOrigin operations? |
| 13:21 | <Domenic> | annevk: you could invent notation for it but it'd not be much shorter than just passing in the spec line that you would plan to write anyway. |
| 13:21 | <annevk> | Domenic: that would avoid a bunch of duplication and make it a little more explicit what the difference actually is |
| 13:21 | <Domenic> | I don't understand, with what I've described there's almost no duplication |
| 13:22 | <annevk> | okay, let me ponder a bit |
| 13:23 | <Domenic> | annevk: I actually can't find any no-return abstract ops in ES... most of them return a completion value. |
| 13:23 | <annevk> | Domenic: I guess I could just return undefined as a new final step that the caller can branch on |
| 13:24 | <Domenic> | annevk: what is this for? |
| 13:24 | <annevk> | Domenic: the named property checkup only needs to happen in the cross-origin case for Window |
| 13:25 | <Domenic> | sure, what does undefined have to do with it? |
| 13:25 | <annevk> | Domenic: so this would be a way to make CrossOriginGetOwnProperty reusable without branching inside the abstract operation on _O_ |
| 13:26 | <Domenic> | Hmm |
| 13:26 | <annevk> | Domenic: rather than throwing in the end it would return undefined, the caller would then be responsible for throwing |
| 13:26 | <Domenic> | You could just branch on the return value being an exception |
| 13:27 | <Domenic> | Nah I guess that doesn't work |
| 13:27 | <Domenic> | if there's e.g. a cross-origin getter that throws a TypeError |
| 13:28 | <Domenic> | Yeah returning undefined seems OK. But I'd rename it to CrossOriginGetOwnPropertyHelper since it no longer has the same semantics as GetOwnProperty. |
| 13:30 | <Domenic> | Well... it kind of does... GOP returns undefined on missing property... but I'd think CrossOriginGOP would throw... I dunno, could go either way. |
| 13:30 | <Domenic> | Probably needs a NOTE though at the top of CrossOriginGOP explaining that the caller is expected to eventually throw |
| 13:34 | <annevk> | happy to name it helper |
| 13:38 | <hallvors> | BTW - two more pending XHR test PRs here: https://github.com/w3c/web-platform-tests/pull/2505 https://github.com/w3c/web-platform-tests/pull/2509 |
| 13:38 | <hallvors> | in case somebody wants to review :) |
| 13:55 | <Ms2ger> | hallvors, did you check if the errorFunc think worked in 2505? |
| 13:58 | <hallvors> | Ms2ger: likely not |
| 13:58 | hallvors | whistles |
| 13:58 | <Ms2ger> | (think?) |
| 13:59 | Ms2ger | needs autocorrect in his brain |
| 14:00 | hallvors | would be very, very worried about a built-in autocorrect in his brain :-p |
| 14:11 | <ritsyy> | philipj: would like to know more for this one https://www.w3.org/Bugs/Public/show_bug.cgi?id=28829 , the wearable should also be mentioned? |
| 14:12 | <MikeSmith> | annevk: @fetchstandard may want to note that Microsoft has announced they will be implementing the Fetch API in Edge |
| 14:12 | <MikeSmith> | annevk: https://twitter.com/jacobrossi/status/694944666827886592 and https://dev.windows.com/en-us/microsoft-edge/platform/status/fetchapi |
| 14:14 | <MikeSmith> | they have moved it to Under Development there in their Platform Status page |
| 14:15 | <MikeSmith> | same for Notifications |
| 14:17 | <MikeSmith> | https://dev.windows.com/en-us/microsoft-edge/platform/status/webnotifications |
| 14:17 | <MikeSmith> | though they link to the old spec, I think we can be confident they'll eventually get on board with the current Notifications spec |
| 14:18 | <MikeSmith> | especially since they have service workers Under Consideration at "Roadmap Priority: High — We intend to begin development soon." |
| 14:18 | <MikeSmith> | https://dev.windows.com/en-us/microsoft-edge/platform/status/serviceworker |
| 14:48 | <MikeSmith> | Ms2ger: what Firefox version will <details> ship in? |
| 14:49 | <annevk> | MikeSmith: done |
| 14:49 | <Ms2ger> | MikeSmith, it hasn't made it to mozilla-central yet, so now +16 weeks or so? |
| 14:50 | <ritsyy> | was referring this issue https://www.w3.org/Bugs/Public/show_bug.cgi?id=27451 and in the spec https://html.spec.whatwg.org/multipage/semantics.html#the-wbr-element i think wbr usage should be explained more thoroughly as it adds the line break in the way user wants when the browser window is resized |
| 14:51 | <Ms2ger> | I think we're in general happy to have more explanatory prose |
| 15:01 | <annevk> | Domenic: what's JS for "is a function"? |
| 15:02 | <Ms2ger> | IsCallable()? |
| 15:02 | <annevk> | ah yeah |
| 15:03 | <JakeA> | annevk: arf https://github.com/ljharb/is-callable/blob/master/index.js |
| 15:03 | <MikeSmith> | Ms2ger: thanks (for release estimate) |
| 15:03 | <Ms2ger> | Np |
| 15:04 | <JakeA> | There should really be Object.isCallable() |
| 15:05 | <annevk> | heh |
| 15:29 | <wanderview> | JakeA: does chrome spin up service workers in incognito mode? |
| 15:29 | <JakeA> | wanderview: yep |
| 15:30 | <JakeA> | wanderview: although I'm not sure push works |
| 15:30 | <wanderview> | JakeA: so it stores the registration and then throws it away at the end of the session? |
| 15:30 | <JakeA> | wanderview: yeah, incognito is pretty much an in-memory profile that disappears with the final incognito tab |
| 15:31 | <wanderview> | JakeA: in FF we disable serviceWorker.register() in private browsing... was thinking its a possible solution for that twitter person's "concerns" |
| 15:32 | <wanderview> | (even though SW is kind of beside the point, etc) |
| 15:32 | <wanderview> | JakeA: from what jsbell told me previously, I think incognito mode in chrome goes to a temp folder on disk... so not pure in-memory |
| 15:34 | <wanderview> | JakeA: another thought I had was, it would be nice if we had a bit in IP or TCP header indicating "metered"... then the part of the network charging by the byte could flip it and browsers could tell even if they are a few steps downstream |
| 15:34 | <wanderview> | but I imagine smarter people have already discussed all that |
| 15:42 | <MikeSmith> | hi ritsyy! |
| 15:43 | <MikeSmith> | agreed that wbr usage should be explained more thoroughly |
| 15:51 | <JakeA> | wanderview: agreed, dunno if it's already a thing |
| 15:51 | <JakeA> | wanderview: the problem with failing .register is it makes private browsing observable, which might be a concern |
| 15:52 | <wanderview> | JakeA: we already fail IDB in private browsing... so yea |
| 15:52 | <JakeA> | ah fair enough, failing for SW is consistent then |
| 15:52 | <wanderview> | JakeA: but we try very hard not to write to disk... so doing pure memory everything is both harder and OOMy |
| 15:52 | <annevk> | Domenic: apart from https://github.com/annevk/html-cross-origin-objects/issues/32 I'm not aware of any issues |
| 15:52 | <wanderview> | in private browsing mode, I mean |
| 15:52 | <annevk> | Domenic: would still be quite some work to put it in HTML of course |
| 15:57 | <Domenic> | JakeA: there should not be; it is redundant with typeof. That repo is overcomplicated for no reason; IsCallable(x) <=> typeof x === "function" |
| 15:58 | <JakeA> | Domenic: hah, good point |
| 16:01 | <Domenic> | annevk: I don't understand https://github.com/annevk/html-cross-origin-objects/issues/32#issuecomment-179912391. COGOPH doesn't need any customizations as written. |
| 16:01 | <annevk> | Domenic: "Let originalDesc be OrdinaryGetOwnProperty(O, P)." |
| 16:02 | <Domenic> | I see |
| 16:04 | <Domenic> | annevk: why does it call OrdinaryGetOwnProperty(O, P) once for each e? That's observable, which seems bad. |
| 16:05 | <annevk> | Domenic: it doesn't? |
| 16:06 | <annevk> | Domenic: it only does it if something is SameValue, which can only happen once |
| 16:06 | <Domenic> | ah right -_- |
| 16:06 | <annevk> | Domenic: how would it be observable though? |
| 16:06 | <Domenic> | maybe i should get some caffeine... |
| 16:06 | <annevk> | Domenic: in the hypothetical case where we have no idea what Window does? |
| 16:07 | <Domenic> | I guess it would not be, I was thinking triggering getters or installing a proxy, but that doesn't make sense |
| 16:07 | <Domenic> | On the other hand, since it's *un*observable, then here's a solution, I think: factor out getting originalDesc into the caller. The caller already has to do so anyway. |
| 16:08 | <annevk> | Hmm, that seems potentially leaky |
| 16:08 | <annevk> | We should only get it I think if it's actually on the safelist |
| 16:09 | <Domenic> | So instead of "3. If IsWindowOrLocationSameOrigin(W), then return OrdinaryGetOwnProperty(W, P). 4. Let property be CrossOriginGetOwnPropertyHelper(W, P)." |
| 16:09 | <Domenic> | it becomes "3. Let property be W.[[GetOwnProperty]](P). 4. If IsWindowOrLocationSameOrigin(W), return property. 5. Set property to CrossOriginGetOwnPropertyHelper(W, P, property)." |
| 16:09 | <Domenic> | hmm why? |
| 16:09 | <Domenic> | I thought we just convinced ourselves it's unobservable... |
| 16:10 | <Domenic> | I guess it does not convey intent great though. |
| 16:10 | <annevk> | I guess what I'm saying is that it makes the setup more fragile |
| 16:11 | <Domenic> | Well, the only thing I can think of is either two algorithms that get inlined into the two [[GOP]]s, which seems fine personally since [[GOP]] has so much variation anyway and the shared code is minor; or, figure out some spec convention for passing "() => W.[[GetOwnProperty(P)]]" and "() => OrdinaryGetOwnProperty(this, P)" to the algorithm... |
| 16:13 | <Domenic> | I guess you could define a helper like you were suggesting, like having DefaultInternalMethod switch on the object type and just keep using that. |
| 16:14 | <annevk> | I was wondering if something like Call([[GetOwnProperty]], W, P) / Call(OrdinaryGetOwnProperty, this, P) would work |
| 16:14 | <Domenic> | Doesn't really work, since [[GOP]] is a method with one argument and OGOP is a function with two arguments |
| 16:16 | <Domenic> | You could maybe just pass a flag as the last parameter to COGOPH |
| 16:17 | <Domenic> | COGOPH(W, P, "delegate") vs. COGOPH(this, P, "use ordinary") |
| 16:18 | <annevk> | Seems reasonable, I might ask bz what he thinks about this |
| 16:18 | <annevk> | But yeah, this seems solvable, so tomorrow the big HTML PR then maybe |
| 16:18 | <Domenic> | \o/ |
| 16:28 | <annevk> | So bz doesn't care since it's not observable, but Gecko does just call the internal method, not the ordinary default internal method |
| 16:28 | <annevk> | So... Meh |
| 16:29 | <annevk> | Oh right, also need TC39 to get back to me on the Ordinary* refactoring stuff I suppose |
| 16:40 | <Domenic> | bterlson ^ |
| 16:40 | <Domenic> | (spec builds are so fast now... whee) |
| 16:41 | <Domenic> | (and I can do just ../build.sh instead of cding up a directory) |
| 16:41 | <annevk> | Domenic: heh |
| 16:42 | <annevk> | Domenic: so the other thing we could do is add some asserts about W not being an exotic object |
| 16:42 | <Domenic> | annevk: I'm starting to feel less strong about all this, and that would help, but I still think it's weird for a proxy not to delegate to its target. |
| 16:43 | <annevk> | Domenic: about the Call() thing earlier, both have the same amount of arguments there; the question is more whether you can rearrange things like that |
| 16:44 | <Domenic> | annevk: they don't... OGOP has two arguments, W.[[GOP]] has one |
| 16:45 | <annevk> | location.assign() has one argument too but you can also do Location.prototype.assign.call(location, argument) iirc |
| 16:45 | <Domenic> | sure but then you can't use the same .call() on a two-argument function and only pass two arguments |
| 16:46 | <Domenic> | you can't do setTimeout.call(fn, time) |
| 16:46 | <annevk> | I think I understand now |
| 16:50 | <Domenic> | time ./build.sh -n 10.6 seconds |
| 16:51 | <Domenic> | and that's on my puny laptop |
| 16:54 | <annevk> | Oh, the other thing aside from JS that needs updating is IDL |
| 16:54 | <annevk> | But I guess we don't have to wait on IDL or even JS, necessarily |
| 16:56 | <Domenic> | both of them accept PRs, although IDL has that super-great spec tooling... |
| 16:56 | <annevk> | I submitted a PR to JS already, and opened an issue with a question on whether another PR would be accepted that went a bit further than cleanup |
| 16:57 | <Domenic> | yeah just waiting for bterlson to get working today I guess |
| 16:57 | <bterlson> | I will be back at ecmascript stuff around 12:00pst for the record :-P |
| 17:02 | <bterlson> | wasn't there another PR on a similar thing just recently? |
| 17:03 | <bterlson> | oh yes, found it, and also see I missed annevk |
| 17:03 | <bterlson> | 's post at the bottom, sorry |
| 17:07 | <annevk> | bterlson: there was another issue, https://github.com/tc39/ecma262/issues/343#issuecomment-178450008 |
| 17:07 | <bterlson> | rgr, sorry aboutnot replying to you |
| 17:15 | <bterlson> | tell me more about perf advancements? |
| 17:15 | <botie> | will do |
| 17:15 | <bterlson> | I want 10s build for ecma262 :-P |
| 17:16 | <bterlson> | probably need to jettison the DOM and have a 1-pass build process |
| 17:25 | <Domenic> | bterlson: well in this case most of the perf improvements were from eliminating downloads and compilation of entities and quote data from CLDR and Unicode. Those things change rarely enough there's no need to update them. |
| 17:25 | <Domenic> | bterlson: the actual build still uses a HTML parser (one hand-crafted by Hixie_ in FreePascal, admittedly) and I am pretty sure it outputs something DOM-like |
| 17:25 | <bterlson> | oh lol |
| 17:25 | <ritsyy> | MikeSmith: hello :) , yeah so i think i could give it a try to add some more points to wbr spec |
| 17:25 | <Domenic> | bterlson: I think you should just work to make jsdom faster :) |
| 17:26 | <bterlson> | Domenic: I would have much fun doing that :-D maybe when I'm not under water 24/7 :-P |
| 17:26 | <Domenic> | ^_^ |
| 17:28 | <Sebmaster> | Domenic: have you tried using jsdom for generating that dom structure? |
| 17:28 | <Domenic> | Sebmaster: which one? bterlson uses it already for the ES spec. |
| 17:29 | <Domenic> | Haven't tried it on the HTML spec though |
| 17:29 | <Sebmaster> | Huh, sweet |
| 17:31 | <Domenic> | Sebmaster: he is why we need to make URL parsing lazy :P |
| 17:31 | <Domenic> | ES spec has lots of <a>s... I am hoping 8.0.0 speeds it up a lot. |
| 17:32 | <Sebmaster> | Oh huh, I wonder how the parser rewrite will impact speed :S |
| 17:33 | <Domenic> | i would guess not much... it removes a small layer of indirection |
| 17:39 | <MikeSmith> | bterlson: Domenic: I'm not sure about the context for what you were discussing about build process and "10s build for ecma262" and the HTML parser for the HTML spec build, but Hixie's HTML does expose a subset of the standard DOM APIs, as well as some custom convenience methods https://github.com/whatwg/wattsi/blob/master/src/html/dom.pas |
| 17:42 | <MikeSmith> | bterlson: and as far as the "10s build" part, I would be surprised if you could end up finding something that would do anything faster than Hixie's parser can. In my environment, it takes less than 4s for it to process the entire 5.8MB HTML spec sourceーto parse it and run all the processing it does to generate the actual fully-formatted spec |
| 17:42 | <MikeSmith> | *Hixie's HTML does *parser* expose a subset of the standard DOM APIs |
| 17:46 | <MikeSmith> | oofs still off by one word there but you know what I mean |
| 17:52 | <bterlson> | MikeSmith: I suspect BS build process is also much less involved than ecma262 so probably 10s is impossible :-P |
| 17:59 | <MikeSmith> | bterlson: yeah I think I fear learning the details of the ecma262 spec :) The output on its own scares me enough already 😆 |
| 18:00 | <MikeSmith> | but if by “BS build process” you mean Bikeshed: For the HTML spec we're not using Bikeshed but instead a custom tool that Hixie wrote that's better :) |
| 18:01 | <MikeSmith> | it's certainly faster |
| 18:02 | <MikeSmith> | Bikeshed would take about 80s at least to process the same source |
| 18:03 | <MikeSmith> | *fear learning the details of the ecma262 spec *build* |
| 18:05 | <caitp> | look on the bright side, at least you don't have to author these things in LaTeX or anything |
| 18:28 | <ritsyy> | how the dfn are defined in the spec, i mean as to add a id https://www.w3.org/Bugs/Public/show_bug.cgi?id=27503 should it not be <dfn data-x="origin-opaque-identifier"> ? |
| 18:29 | <Domenic> | ritsyy: that sounds about right |
| 18:30 | <ritsyy> | Domenic: okay actually i got confused with the concept-origin , you mentioned in the comment |
| 18:30 | <Domenic> | ritsyy: oh. Well, we usually start IDs for things like that with a "concept-" prefix, so yeah, maybe include that. |
| 18:31 | <ritsyy> | Domenic: okay could you explain a bit, i mean why "concept-" is used |
| 18:32 | <Domenic> | ritsyy: it's not followed everywhere, but it seems like the idea is to use "concept-" for things that are conceptual, "dom-" for APIs, and there are a few others... I think there was a document on the wiki somewhere... |
| 18:33 | <ritsyy> | Domenic: oh okay, thanks got your point |
| 18:35 | <Domenic> | ritsyy: here is the list https://wiki.whatwg.org/wiki/Specs/howto#Definitions we should maybe put that in the readme or something... |
| 18:37 | <ritsyy> | Domenic: yeah mentioning some heading for these points and their wiki links would be helpful in the readme |
| 20:24 | <bterlson> | MikeSmith: is this the wattsi tool that you're using? |
| 20:25 | <bterlson> | MikeSmith: you must not have too much generation going from source doc --> output doc I guess? |
| 20:25 | <bterlson> | MikeSmith: just curious how it's so fast :-P |
| 20:32 | <Domenic> | bterlson: there's a lot of generation... |
| 20:32 | <Domenic> | bterlson: it's an AOT language I guess |
| 20:32 | <Domenic> | and an optimized DOM instead of a general purpose one, I presume |
| 20:33 | <Domenic> | philipj: in https://github.com/whatwg/html-build/pull/75, what do you mean about those being removed? Is that bad? Or is it more, they should never have been linked in the first place? |