| 01:57 | <DRWhite> | Why is Synchronous AJAX requests bad? |
| 01:59 | <DRWhite> | I get "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/"; all the time, and it's bad? |
| 01:59 | <TabAtkins> | Because sync XHR blocks all JS while it's waiting for the network request to finish. |
| 01:59 | <TabAtkins> | Which means nothing else on the page will work, giving a bad user experience. |
| 02:00 | <DRWhite> | So why not, as per usual, provide the OPTION? |
| 02:01 | <DRWhite> | Why are we forced to have it asynchronous when the app has to wait for the response anyway? |
| 02:03 | <Domenic> | DRWhite: because you are hurting the *user*. It doesn't just block your app; it blocks the *user* using their browser. |
| 02:05 | <DRWhite> | Please explain how my program performing a single request can affect the users browser and stop the whole browser from working while it does a single request? |
| 02:05 | <Domenic> | DRWhite: that's what synchronous *means*, is that it stops the browser |
| 02:05 | <Domenic> | DRWhite: I can link you to the C++ if that would help? |
| 02:05 | <Domenic> | Showing how it is implemented in browsers, to stop the entire event loop |
| 02:06 | <DRWhite> | I've had synchronous AJAX requests running in multiple tabs, while still browsing, that is why I don't know why this is an issue. |
| 02:06 | <DRWhite> | And thus I'm trying to find out why. |
| 02:06 | <Domenic> | Yes, in some browsers people can use other tabs. But they can't use your tab. |
| 02:07 | <Domenic> | Taking the ability to e.g. scroll a tab away from the user is not acceptable, especially when it's just lazy coding to use sync XHR instead of async. |
| 02:08 | <DRWhite> | So the fact that my tab is waiting for information BEFORE it can continue, that means that the users experience is bad? |
| 02:08 | <Domenic> | Yes |
| 02:08 | <Domenic> | You can block parts of your app if you want, e.g. by disabling buttons or putting up gray loading boxes in front of the UI |
| 02:09 | <Domenic> | But blocking the entire event loop is not OK |
| 02:09 | <DRWhite> | So I have a form posting, and I have to wait for a response to know what message to show and what page to go to next... And I'm not allowed to wait for the response before I send them on? |
| 02:09 | <Domenic> | You certainly should wait for the response! Just use a callback! |
| 02:09 | <DRWhite> | I tried using a callback, but the callbacks don't work in JQuery 2. |
| 02:10 | <Domenic> | They definitely do |
| 02:10 | <Domenic> | They're just async |
| 02:10 | <DRWhite> | I can't get them to work, no matter what Tutorials I go to on the JQuery website. |
| 02:10 | <Domenic> | This is probably getting into "good StackOverflow question" territory :) |
| 02:10 | <DRWhite> | So the things that I built ages ago, I can't use any more? |
| 02:12 | <DRWhite> | Domenic: I know that they are async. Even if I force them to be sync, they still don't work. |
| 02:13 | <Domenic> | DRWhite: I'd suggest asking a StackOverflow question to get help making it work. It sounds like the question about sync vs. async is not really related to your problem. |
| 02:13 | <DRWhite> | I'll see if I can get assistance elsewhere perhaps then. Thanks for informing me and helping me understand better,. |
| 02:13 | <DRWhite> | I don't ask on stackOverflow. |
| 09:39 | <annevk> | MikeSmith: it seems sudo is required for me to build wattsi, not sure what's up |
| 09:40 | <annevk> | MikeSmith: otherwise I get "ld: can't write output file: ../bin/wattsi for architecture x86_64" |
| 09:40 | <annevk> | MikeSmith: there's a ton of warnings btw while building wattsi, should we attempt to fix some of them? |
| 10:12 | <zcorpan> | does someone have Edge? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3804 |
| 10:17 | <MikeSmith> | annevk: as far as the warnings, I just raised a PR that fixes that https://github.com/whatwg/wattsi/pull/11 |
| 10:17 | <MikeSmith> | fixes it by suppressing them |
| 10:18 | <MikeSmith> | but only suppresses them for the "release" build; they still get emitted for the debug build |
| 10:19 | <MikeSmith> | that seems to me like the right way to handle it, because there's not point in normal contributors needing to see them |
| 10:21 | <MikeSmith> | if we want to really eliminate them by making changes to the source, it's possible to do that (some of it would amount to just explicitly casting a bunch of stuff) but I think it's probably not worth it, and I reckon Hixie thought the same, because the entire purpose of the https://github.com/whatwg/wattsi/blob/master/src/lib/filter.pl script is to filter them out |
| 10:21 | <MikeSmith> | but for some reason Hixie only has that filter.pl script set to run for everything but the release build |
| 10:23 | <MikeSmith> | anyway I like my brute-force suppress-all-the-things approach better, at least for the release build |
| 10:24 | <MikeSmith> | it's only suppressing known messages (mostly note-level and "hint"-level), so if we do actually introduce some new non-error-level problem, we'll still see it, even for the release build |
| 10:26 | <annevk> | I see |
| 10:26 | <MikeSmith> | annevk: about the "ld: can't write output file: ../bin/wattsi for architecture x86_64" problem, have you already checked the obvious stuff, like, the bin directory is writable by non-root/you, and there's no bin/wattsi file in there that's owned by root that you're trying to overwrite |
| 10:27 | <MikeSmith> | like, do a sudo rm bin/wattsi and then re-run the build non-root |
| 10:28 | <annevk> | MikeSmith: have not tried obvious stuff... |
| 10:32 | <annevk> | MikeSmith: ta, works |
| 10:33 | <MikeSmith> | k |
| 10:34 | <MikeSmith> | I'll try to get the various other open wattsi changes reviewed and merged asap |
| 11:13 | <annevk> | Oh interesting, I totally missed Domenic added a bunch of changes to the type=module issue |
| 11:25 | <IZh> | Hi Hixie, Domenic. My PDF-generator return errors because the refers to non-existing document: //html.spec.whatwg.org/demos/canvas/blue-robot/index-idle.html |
| 11:25 | <zcorpan> | i wanted an html diff, but w3c's service uses Tidy which chokes on <mark> :-( |
| 11:26 | <IZh> | Hixie, Domenic: the = the spec |
| 11:27 | <annevk> | IZh: https://github.com/whatwg/html/issues/30 has the culprit somewhere |
| 11:27 | <annevk> | IZh: Domenic has been moving the demos around |
| 11:28 | <IZh> | annevk: Okay. So I will wait. (Or I can fix the PDF-generator to ignore this error.) |
| 11:28 | <zcorpan> | looks like the file is now named index.html but the link is still index-idle.html |
| 11:29 | <annevk> | zcorpan: no, one file was not moved |
| 11:29 | <annevk> | IZh: could you add a comment to that issue? I think you found a file that was overlooked |
| 11:30 | <zcorpan> | annevk: oh |
| 11:34 | <IZh> | annevk: Done. |
| 11:34 | <Ms2ger> | > CSV on the Web Recommendations Published |
| 11:36 | <annevk> | IZh: thank you |
| 12:37 | <zcorpan> | annevk: do you want a "good first bug" label for url? |
| 12:37 | <annevk> | zcorpan: sure |
| 12:38 | <annevk> | zcorpan: should probably also have some "Contribution opportunities" thing in the README then at some point |
| 14:05 | <annevk> | If someone could figure out how gb18030 actually works that'd be great |
| 14:05 | <annevk> | So many conflicting sources |
| 14:08 | <gsnedders> | "magic" |
| 14:37 | <smaug____> | hmm, has W3 changed the style for specs in general |
| 14:37 | <smaug____> | I thought only that one CSS spec was using odd style |
| 14:38 | <smaug____> | but apparently also webrtc |
| 14:38 | <smaug____> | maybe I get used to it |
| 15:15 | <zcorpan> | MikeSmith: so... html-build is downloading various stuff. could it download things in parallel? |
| 15:20 | <zcorpan> | hmm the new stylesheet seems to expose some bug with the fixed background in blink when first scrolling the TOC a bit and then scrolling the viewport |
| 16:33 | <zcorpan> | is there an issue filed on github that comments on specific commits disappear from the PR when rewriting history (but not when commenting from "Filed changed" tab) ? |
| 21:58 | <smaug____> | majidvp: did you already update http://majido.github.io/scroll-restoration-proposal/tests/scroll-restoration-push-replace.html ? |
| 22:11 | <majidvp> | smaug:____: yes |
| 22:11 | <smaug____> | majidvp: ok. thanks |
| 22:11 | <smaug____> | majidvp: btw, as I said in the bug, the test is still buggy, technically |
| 22:11 | <smaug____> | nothing says browser should scroll |
| 22:12 | <majidvp> | smaug____: I think you are right. |
| 22:12 | <smaug____> | which makes testing hard |
| 22:12 | <smaug____> | I'm fixing this sure |
| 22:12 | <smaug____> | but I wonder what the spec should say here |
| 22:13 | <majidvp> | smaug____: 'auto' does not require scrolling. For chromium test I am actually verifying that we scroll but that is not necessary per spec. |
| 22:16 | <smaug____> | majidvp: one option is to just make sure in wpt tests that 'manual' does *not* scroll, since that is the only thing the spec requires |
| 22:16 | <smaug____> | and not test scrolling at all |
| 22:17 | <majidvp> | smaug____: That is probably right for wpt test covering the spec. Each UA will have its own test covering its own specific implementation of auto. |
| 22:18 | <smaug____> | right |
| 22:18 | smaug____ | sees the relevant bug in gecko. |
| 22:18 | <smaug____> | silly me |
| 22:29 | <majidvp> | sometimes, even a broken test may prove itself useful :p |
| 22:34 | <smaug____> | majidvp: it was effectively two line change to fix it :) |
| 22:35 | <smaug____> | in gecko |