| 00:02 | <MikeSmith> | thanks, retweeted |
| 07:52 | <ritsyy> | i am trying to install wattsi first downloaded this ftp://freepascal.stack.nl/pub/fpc/beta/3.0.0-rc1/x86_64-linux/ but the install.sh is giving errors, |
| 07:54 | <ritsyy> | it's done now :D |
| 07:57 | <zcorpan> | MikeSmith: can you make the warning in https://www.w3.org/TR/html-markup/ be something that always floats on top, on every page? see https://github.com/htacg/tidy-html5/issues/348#issuecomment-172571746 |
| 08:03 | <zcorpan> | though not sure if web platform docs is a good reference to point to... "Using async="async" didn't work in some older browser, instead async="true" was used."? http://docs.webplatform.org/wiki/html/elements/script |
| 08:06 | <ritsyy> | getting these errors while compiling wattsi https://paste.kde.org/pc0qsqmtp |
| 08:12 | <ritsyy> | annevk: ^ |
| 08:34 | <annevk> | ritsyy: those are not errors, seems like you have a binary now |
| 08:35 | <annevk> | ritsyy: you don't need a beta of Pascal anymore though |
| 08:36 | <ritsyy> | annevk: but the build script still shows up on local wattsi installed |
| 08:36 | <annevk> | Not sure what you mean |
| 08:37 | <ritsyy> | annevk: actually i didn't get about the binary |
| 08:38 | <ritsyy> | and when i run the html-build script it says no local wattsi installed |
| 08:38 | <annevk> | Hmm |
| 08:40 | <annevk> | Install a non-beta of Pascal 3.0.0 and try again? |
| 08:40 | <ritsyy> | annevk: okay i try that |
| 08:40 | <annevk> | Not sure why compile tries to run wattsi |
| 08:41 | <annevk> | MikeSmith is maybe better at this |
| 08:41 | <annevk> | Or maybe stackoverflow / linux IRC channels? |
| 08:41 | <annevk> | Anyway, back in a bit |
| 08:42 | <ritsyy> | annevk: okay yeah, i ask on that channel too |
| 09:13 | <MikeSmith> | zcorpan: oh man |
| 09:13 | <MikeSmith> | zcorpan: yeah I'll do it tonight |
| 09:13 | <zcorpan> | MikeSmith: cool |
| 09:16 | <MikeSmith> | ritsyy: you need to make sure the directory of your wattsi binary is in your bash PATH |
| 09:17 | <ritsyy> | MikeSmith: i removed that install and tried with the fpc non-beta version |
| 09:17 | <ritsyy> | MikeSmith: Error: ppcx64 can't be executed, error message: Failed to execute "ppcx64", error code: 127 ,getting this now |
| 09:17 | <ritsyy> | |
| 09:19 | <MikeSmith> | Oh |
| 09:19 | <MikeSmith> | that sounds vaguely familiar |
| 09:20 | <MikeSmith> | But if the beta works for you, it's fine to use the beta |
| 09:21 | <ritsyy> | yeah it was giving those errors i stated above, so just thought to try non-beta, working on this error now |
| 09:23 | <MikeSmith> | The messages in your earlier pastebin aren't actually errors |
| 09:23 | <MikeSmith> | they're just info messages and warnings |
| 09:24 | <MikeSmith> | The pastebin indicates that your build succeeded |
| 09:24 | <ritsyy> | MikeSmith: but the html-build script still showed no local wattsi installed |
| 09:25 | <ritsyy> | and then the build script abort with a broken pipe error |
| 09:25 | <MikeSmith> | yeah I think that's because of the PATH issue |
| 09:26 | <MikeSmith> | you need to do something like "export PATH=/home/wattsi:$PATH" |
| 09:27 | <MikeSmith> | ..where "/home/wattsi" is whatever directory where you ran the wattsi build script |
| 09:28 | <MikeSmith> | the directory that contains the watsii build.sh script |
| 09:28 | <MikeSmith> | that's where it also places the wattsi binary |
| 09:28 | <MikeSmith> | I think |
| 09:29 | <MikeSmith> | But I can't check for sure right now because I'm on from my phone at the moment |
| 09:29 | <MikeSmith> | it may be in a "bin" subdirectory of the directory |
| 09:30 | <ritsyy> | MikeSmith: oh ok i'll try setting this path actually the new non-beta version is downloading right now, so after fpc i'll do that |
| 09:30 | <MikeSmith> | k |
| 09:31 | <annevk> | I retweeted that Docker thing from @whatwg too |
| 09:31 | <MikeSmith> | I'll be on from my phone for another hour or so, then beck at my pc after |
| 09:31 | <MikeSmith> | annevk: cool |
| 09:32 | <MikeSmith> | there's somebody already been hacking on it who may already have what we need |
| 09:32 | <MikeSmith> | quick work |
| 09:35 | <annevk> | wow, great |
| 09:56 | <ritsyy> | MikeSmith: http://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux there is one for binary and a path for directory which should be done? |
| 09:59 | <MikeSmith> | ritsyy: nothing to be undone, but just added |
| 10:00 | <MikeSmith> | since the PATH value is just a colon-separated list of pathnames, you just need to add one more pathname to it |
| 10:01 | <ritsyy> | MikeSmith: yeah okay |
| 10:31 | <mounir> | Ms2ger: are you one of the people taking care of webidl spec? |
| 10:31 | <Ms2ger> | I have touched it |
| 10:32 | <mounir> | Ms2ger: who does PR reviews/merging? |
| 10:32 | <Ms2ger> | Nobody |
| 10:32 | <mounir> | oh, that sounds amazing |
| 10:32 | <Ms2ger> | With s/does/should do/, heycam |
| 10:45 | <annevk> | Yeah, we need to sort something out there |
| 11:17 | <ritsyy> | MikeSmith: annevk: i have set the path but it's the same error showing up, https://paste.kde.org/pc0qsqmtp |
| 11:21 | <annevk> | ritsyy: |
| 11:22 | <annevk> | ritsyy: I get that too when I compile wattsi, but afaict that means it's done |
| 11:22 | <annevk> | ritsyy: what do you get if you type wattsi and hit enter? |
| 11:22 | <ritsyy> | annevk: command not found |
| 11:23 | <mounir> | annevk, Ms2ger: I thought bz and others were helping in order to make this spec more responsive |
| 11:23 | <annevk> | ritsyy: where did you install wattsi? |
| 11:23 | <ritsyy> | localhost |
| 11:23 | <Ms2ger> | bz is co-editor, but also has a million other things on his plate |
| 11:23 | <annevk> | mounir: not sure which others? |
| 11:23 | <mounir> | annevk: not sure either, otherwise I would have named :) |
| 11:23 | <mounir> | annevk: maybe others = {} :) |
| 11:23 | <annevk> | ritsyy: localhost? it must be in a directory somewhere, no? |
| 11:24 | <ritsyy> | annevk: /var/www/html/wattsi |
| 11:24 | <annevk> | ritsyy: if you go there and then run ./bin/wattsi |
| 11:24 | <annevk> | ritsyy: what does that give? |
| 11:25 | <ritsyy> | annevk: wattsi: invalid arguments |
| 11:25 | <ritsyy> | syntax: |
| 11:25 | <ritsyy> | wattsi [--quiet] <source-file> <output-directory> <caniuse.json> <bugs.csv> |
| 11:25 | <annevk> | ritsyy: okay, so wattsi is installed but something is wrong with your PATH |
| 11:26 | <ritsyy> | i did set it to export PATH="/var/www/html/wattsi:$PATH" |
| 11:26 | <ritsyy> | annevk: ^ |
| 11:26 | <annevk> | ritsyy: what does echo PATH return? |
| 11:27 | <annevk> | ritsyy: also, I think that needs to be /var/www/html/wattsi/bin since the compiled script is inside bin |
| 11:27 | <annevk> | ritsyy: echo $PATH |
| 11:28 | <ritsyy> | annevk: its showing this path https://paste.kde.org/p8rjnx9he |
| 11:30 | <annevk> | ritsyy: yeah so as MikeSmith mentioned you should use the path that points to the directory where wattsi is in, which is /bin |
| 11:30 | <annevk> | ritsyy: well, has /bin at the end, given that the wattsi binary is there |
| 11:30 | <ritsyy> | annevk: yeah i am adding /bin in the path |
| 11:44 | <ritsyy> | annevk: path is this now https://paste.kde.org/pgf8feuq7 and when i enter wattsi it gives https://paste.kde.org/pe5ul1zjj |
| 11:44 | <annevk> | ritsyy: great |
| 11:44 | <annevk> | ritsyy: build script should work now |
| 11:45 | <annevk> | ritsyy: (you might want to clean up your path to remove the bits that were pointing to the wrong folder) |
| 11:47 | <ritsyy> | annevk: but the script is showing this still Local wattsi is not present; trying the build server... |
| 11:48 | <ritsyy> | annevk: yeah right i am clearing that path |
| 11:48 | <annevk> | ritsyy: hmm that's weird |
| 11:49 | <ritsyy> | annevk: okay i think i should try after clearing that path |
| 11:51 | <annevk> | ritsyy: one thing you could try with debugging is to change the build script |
| 11:52 | <annevk> | ritsyy: in "function runWattsi" you basically only want to run the code after the if statement, and not the code after the else statement; so if you remove the conditionals and the code you don't want to run, it'll be forced to use wattsi (and maybe emit some other kind of error) |
| 11:52 | <annevk> | ritsyy: if that doesn't work MikeSmith will have to help since I'm not sure what "hash wattsi 2>/dev/null;" does, really |
| 11:52 | <ritsyy> | annevk: okay i am seeing that just a second |
| 11:53 | <annevk> | (if it does work you should file a bug against html-build since that means that if statement is a little bogus or at least doesn't work across platforms) |
| 11:54 | <ritsyy> | annevk: you are right i'll try running by removing that else part now |
| 11:54 | <zcorpan> | ritsyy: try starting a new terminal window after changing $PATH. dunno if it is necessary but maybe? |
| 11:55 | <annevk> | I'm gonna get some lunch, back later |
| 11:55 | <ritsyy> | zcorpan: i did that :) |
| 11:55 | <zcorpan> | k :-) |
| 12:01 | <MikeSmith> | ritsyy: not sure if anybody asked this already, but if you just type "wattsi" at the command prompt, does it report "wattsi: command not found"? |
| 12:02 | <ritsyy> | MikeSmith: not now after setting the path to bin now it reports this https://paste.kde.org/pe5ul1zjj |
| 12:02 | MikeSmith | looks |
| 12:02 | <MikeSmith> | ok good |
| 12:02 | <MikeSmith> | yeah, that's right then |
| 12:02 | <MikeSmith> | so the shell can find it |
| 12:03 | <MikeSmith> | and so the build script should be able to as well |
| 12:03 | <ritsyy> | MikeSmith: but the build-script says the same Local wattsi is not present; trying the build server... |
| 12:04 | <ritsyy> | MikeSmith: yeah it's weird, i am doing it now with annevk's suggestion |
| 12:05 | <MikeSmith> | yeah OK so then I guess as annevk suggested, my check of the exit status for "hash wattsi 2>/dev/null;" in the build script is failing for some reason (though I have not idea why it would fail, because it's something built into the bash shell) |
| 12:05 | <MikeSmith> | ritsyy: what does "echo $PATH" say? |
| 12:06 | <ritsyy> | MikeSmith: https://paste.kde.org/phccmrt1o this |
| 12:07 | <MikeSmith> | OK so yeah that looks correct |
| 12:09 | <MikeSmith> | ritsyy: what does "hash wattsi; echo $?" say? |
| 12:10 | <ritsyy> | MikeSmith: 0 |
| 12:11 | <MikeSmith> | ok yeah that's right too then |
| 12:11 | <MikeSmith> | puzzling |
| 12:12 | <ritsyy> | MikeSmith: yeah it is behaving weird |
| 12:12 | <MikeSmith> | oh wait |
| 12:13 | <MikeSmith> | ritsyy: how about what does "hash wattsi 2>/dev/null; echo $?" say? |
| 12:13 | <ritsyy> | MikeSmith: 0 |
| 12:14 | <MikeSmith> | oh |
| 12:14 | <MikeSmith> | so yeah, still puzzled |
| 12:16 | <ritsyy> | :-/ me too |
| 12:47 | <annevk> | ritsyy: how do you run the build script? just ./build.sh? |
| 13:28 | <ritsyy> | annevk: yes with sudo ./build.sh, is it wrong? |
| 13:29 | <Ms2ger> | Why with sudo? |
| 13:29 | <annevk> | ritsyy: you shouldn't need sudo |
| 13:29 | <annevk> | nothing from HTML needs sudo |
| 13:29 | <ritsyy> | Ms2ger: annevk: yeah it's the same but foe wattsi without sudo it gives a ppcx64 error |
| 13:29 | <ritsyy> | for* |
| 13:30 | <annevk> | Yeah, I suspect that might because once you compile it with sudo once, certain files can only be touched with sudo |
| 13:30 | <MikeSmith> | oh yeah |
| 13:31 | <annevk> | I think the way I fixed that locally was by clearing the bin dir with sudo |
| 13:31 | <annevk> | And then compiling again |
| 13:31 | <MikeSmith> | yeah, don't need sudo |
| 13:31 | <ritsyy> | annevk: ohk i am trying that too |
| 13:31 | <annevk> | Not sure if running it with sudo should cause it to stop working though, that too seems strange |
| 13:32 | <annevk> | ritsyy: did you try modifying the build script already? |
| 13:32 | <ritsyy> | annevk: yeah i did but it gives error then |
| 13:33 | <annevk> | ritsyy: what kind? |
| 13:34 | <ritsyy> | ah i changed it many a times actually, i tried that >2 condition too with these http://unix.stackexchange.com/questions/163352/what-does-dev-null-21-mean-in-this-article-of-crontab-basics |
| 13:35 | <ritsyy> | just a second, changing the script actually it didn't fixed so i just removed the changes |
| 13:35 | <Ms2ger> | >2 just changes what's logged where |
| 13:36 | <ritsyy> | Ms2ger: actually the problem is starting from here "if hash wattsi 2>/dev/null; then" |
| 13:37 | <ritsyy> | that's why i tried, had not much idea about it |
| 13:38 | <annevk> | To be clear, the way you want to modify that is to remove that if statement, remove the else statement and everything that follows it (within the limits of the function) so that the function only executes what is between the if and the else statement |
| 13:47 | <ritsyy> | annevk: yeah i did this https://paste.kde.org/plwrwjpud commented this code, but it is running the script right now, |
| 13:48 | <annevk> | ritsyy: you also need to comment out "if hash wattsi 2>/dev/null; then" and "else" and the $QUIET lines and the final "fi" |
| 13:48 | <ritsyy> | annevk: https://paste.kde.org/pedlrqrf6 got this |
| 13:48 | <annevk> | ritsyy: otherwise you're not forcing that code to run |
| 13:48 | <annevk> | ooh |
| 13:48 | <annevk> | ritsyy: so that's good, no? |
| 13:49 | <annevk> | ritsyy: it means the build script found a mistake in your source document |
| 13:49 | <ritsyy> | annevk: yeah i think so, wattsi ran i think |
| 13:49 | <annevk> | ritsyy: so I guess everything is working |
| 13:49 | <annevk> | ritsyy: and I guess you don't need a modification of the build script then |
| 13:49 | <ritsyy> | annevk: i did these modifications but |
| 13:50 | <ritsyy> | but that didn't made sense, |
| 13:50 | <annevk> | What doesn't make sense? |
| 13:52 | <ritsyy> | annevk: the code i commented |
| 13:55 | <zcorpan> | Hixie_: RED ALERT! THE SAVE THING IN LIVE DOM VIEWER APPEARS BROKEN. I CANNOT WORK WITHOUT IT |
| 13:58 | <ritsyy> | annevk: i meant the code i commented out didn't forced the script to run anyhow, but now i tried both by commenting out and without it now and the error is in the source, yay \o/ |
| 13:59 | <ritsyy> | annevk: MikeSmith: thanks :) |
| 14:00 | <annevk> | ritsyy: super happy this is working now |
| 14:01 | <zcorpan> | 2>/dev/null means to direct strerr to /dev/null, i.e. mute errors |
| 14:01 | <ritsyy> | annevk: yeah me too :) |
| 14:02 | <ritsyy> | zcorpan: yeah got that now, thanks :) |
| 14:06 | <MikeSmith> | ritsyy: yeah also very glad it is working now |
| 14:06 | <MikeSmith> | ritsyy: and also sorry the build is as much work as it is |
| 14:07 | <MikeSmith> | if it's any consolation, your experience with it is giving us a lot of motivation to make it much easier for future contributors |
| 14:08 | <MikeSmith> | so you're helping other people by being a pioneer :) |
| 14:12 | <ritsyy> | MikeSmith: no worries i actually enjoyed it now, feeling so much happy now |
| 14:13 | <ritsyy> | MikeSmith: yeah it is going to be a very good prize for this day's work for me, thanks :) |
| 16:27 | Krinkle | smiles at seeing "Web Worker" on someone's resume as a previous job title. |
| 16:43 | <rbyers> | smaug, miketaylr: how much web compat pain do you feel from Mozilla not having support for 'mousewheel' events? I'd like to consider removing support from blink (in favor of standard 'wheel' events which we've long supported). |
| 17:05 | <miketaylr> | rbyers: i'm not aware of any sites that are broken due to us lacking mousewheel events, but that's probably because i focus more on mobile ^_^ |
| 17:05 | <miketaylr> | smaug____ might have more insight there, but i'll poke around bugzilla |
| 17:06 | <rbyers> | miketaylr: Ok, thanks! Sadly we don't yet have a usecounter for this - adding one now. Probably too hard to search httparchive for. |
| 17:06 | <miketaylr> | and probably filled with scripts that just try to copy every possible event, etc. |
| 17:08 | <rbyers> | Yep. Interestingly our behavior is not to fire mousewheel on a node if that node has ANY wheel listeners. I'm kind of surprised that hasn't caused compat issues (eg. with multiple scripts from multiple places all listening on window or documentElement). |
| 17:08 | <smaug____> | rbyers: I don't recall many bugs, especially not recent bugs about mousewheel |
| 17:09 | <rbyers> | Thanks. And Firefox has dropped DOMMouseScroll (or any other non-standard API) for this, right? |
| 17:10 | <rbyers> | That's pretty promising. |
| 17:10 | <smaug____> | rbyers: since Gecko has had its own non-spec'ed DOMMouseScroll for ages, most pages (which aren't using 'wheel') I've looked do something like window.addEventListener(window.onmousewheel ? "mousewheel" : "DOMMouseScroll", listener); |
| 17:10 | <smaug____> | rbyers: DOMMouseScroll is still there |
| 17:11 | <rbyers> | Oh shoot, so that means Firefox probably isn't a good proxy for the pain I'd feel by trying to remove mousewheel from blink. Ok, thanks anyway. |
| 17:11 | <smaug____> | 'wheel' is after all relatively new addition to the platform |
| 17:16 | <rbyers> | Yeah, indeed. FWIW it's looking like I might not be able to fix scrollTop unless I also remove mousewheel ;-) |
| 17:17 | <smaug____> | "fun" |
| 17:17 | <rbyers> | http://crbug.com/501568 |
| 17:17 | <miketaylr> | just remove all events, and add 'em back one by one as people complain |
| 17:17 | <smaug____> | hmm, I guess browsers should start warn about use of mousewheel or DOMMouseScroll events |
| 17:22 | <rbyers> | Yeah I'd add a deprecation warning if the usage is low enough. |
| 17:23 | <rbyers> | (we don't want to train developers to ignore deprecation warnings by spamming them with ones for things we're realistically unlikely to actually remove anytime soon) |
| 17:23 | <rbyers> | But it's not looking good. Just checked 3 random sites: Facebook, GMail, Google sheets - all use 'mousewheel' + 'DOMMouseScroll' instead of wheel :-( |
| 17:23 | <Domenic> | IIRC all three have different semantics? |
| 17:24 | <Domenic> | Otherwise I'd say just standardize all three as aliases |
| 17:24 | <rbyers> | Yeah, slightly different APIs |
| 17:24 | <rbyers> | wheel and mousewheel are similar. |
| 17:24 | <Domenic> | I guess that doesn't help your scrollLeftTopInterop problem either |
| 17:24 | <rbyers> | No, but you already predicted I wouldn't be able to fix that one ;-) |
| 17:28 | <rbyers> | Actually I believe blink fires identical WheelEvent objects for wheel and mousewheel listeners. We just have 3 non-standard properties on WheelEvent - wheelDelta, wheelDeltaX, wheelDeltaY (IIRC the signs may be reversed). |
| 17:28 | <smaug____> | so I'm worried that if blink can't fix scroll* issue, scrollingElement is totally useless and should be removed from the platform |
| 17:34 | <rbyers> | It depends what we want to do about not fixing scroll* issue. If we want to leave implementations as they are, then scrollingElement is VERY useful - it lets you detect the bug (and we should just update the spec to match that). |
| 17:34 | <gsnedders> | when does load fire relative to web font loading? (assumign there's no modifications to the DOM that affect font selection, etc.) |
| 17:35 | <rbyers> | Otherwise there's no good choice but to rely on UA sniffing to decide between document.body and document.documentElement... |
| 17:36 | <rbyers> | But if, instead, we want to just change Firefox and the spec to match WebKit/Edge (so scrollingElement is almost always body - like for quirksmode pages), then yes there isn't much value to scrollingElement anymore. |
| 17:38 | <rbyers> | The argument against changing the spec to match WebKit's behavior is that then the weird cases (eg. "html, body { overflow: scroll }") become even weirder - scrollingElement==null (can't detect/set document scroll position via scrollTop at all). |
| 17:40 | <rbyers> | Actually, even in that option, scrollingElement is critical in managing the transition. Firefox could just switch to WebKit behavior and sites (google properties, facebook, etc.) would just work due to all the outreach we've done to get them to depend on scrollingElement. Sites that are still relying on a WebKit UA check will be broken in Firefox if |
| 17:40 | <rbyers> | Firefox switches to the WebKit model without also adding "WebKit" to the UA string. |
| 17:42 | <smaug____> | yeah, this is difficult issue |
| 17:42 | <smaug____> | and there is still IE11 |
| 17:43 | <smaug____> | and 10 too |
| 17:43 | <smaug____> | (or was 10 deprecated) |
| 17:48 | <smaug____> | rbyers: do you know roughly how many (%) sites are broken with scrollLeftTopInterop==true? |
| 17:51 | <smaug____> | oh, hmm, that chromium bug is about smoothscrolling. perhaps the use of it will now decrease when smoothscrolling is enabled |
| 17:56 | <smaug____> | rbyers: have you asked MS if they have plans to change their behavior, or will they just follow what blink does? |
| 17:56 | <smaug____> | or what about webkit? |
| 18:12 | <annevk> | terinjokes: if you add Console Standard to https://resources.whatwg.org/biblio.json other specifications can reference it |
| 18:24 | <kbrosnan> | /window close |
| 18:24 | <terinjokes> | annevk: where does that come from? |
| 18:25 | <annevk> | terinjokes: https://github.com/whatwg/resources.whatwg.org |
| 18:25 | <annevk> | terinjokes: and then it's imported by some tool tobie wrote to get references between specs in some consistent fashion |
| 18:30 | <terinjokes> | annevk: https://github.com/whatwg/resources.whatwg.org/pull/13 |
| 18:49 | <TabAtkins> | terinjokes: And I just put Console into Shepherd, so Bikeshedded specs will get access to it once it fetches. |
| 18:49 | <TabAtkins> | But def do what anne is saying to get it into Bikeshed's biblio db as well. |
| 18:50 | <TabAtkins> | annevk: Do you know what other whatwg specs are Bikeshedded? I've got URL, DOM, and Console in there now. |
| 18:50 | <terinjokes> | TabAtkins: i added it to the biblio, and it's been merged |
| 18:50 | <TabAtkins> | +1 |
| 18:50 | <tobie> | terinjokes: the updater bot should kick in in about 45 minutes |
| 18:51 | <tobie> | terinjokes: then you'll get it here: http://www.specref.org/?q=console |
| 18:52 | <terinjokes> | ooh. i'm really interested in using an IBM 2741 terminal |
| 18:53 | <TabAtkins> | I love the RFCs. |
| 19:11 | <rbyers> | smaug____: I don't have any good way to quantify the sites broken with scrollTopLeftInterop=true. I know it's not huge anymore because we have a non-trivial number of users running with enable-experimental-web-platform-features turned on and I'm no longer getting many complaints from them (after getting a bunch of top sites fixed). |
| 19:12 | <rbyers> | smaug____: But I know it's at least 0.26% of the top websites based on the httparchive search for smoothscroll.js code |
| 19:12 | <smaug____> | rbyers: ok, sounds good. Is there any Gecko could do to hint to web devs to move to different APIs? |
| 19:12 | <smaug____> | s/any/anything |
| 19:12 | <rbyers> | And yes I've talked to both Edge and WebKit folks - they're prepared to follow us in fixing scrollTop if we can show we were able to do it without terrible web compat impact. |
| 19:13 | <smaug____> | I guess use of DOMMouseScroll is one thing |
| 19:13 | <rbyers> | Trying to deprecate DOMMouseScroll might help |
| 19:13 | <rbyers> | Yeah |
| 19:13 | smaug____ | files a bug to track that |
| 19:13 | <rbyers> | But that's probably a bigger problem |
| 19:13 | <rbyers> | Usage is probably so high as to not be the best use of our collective time. |
| 19:14 | <smaug____> | true, if FB and Google are using it |
| 19:14 | <rbyers> | I'm adding a use counter to track mousewheel (but not wheel) usage - I expect it'll be high. |
| 19:14 | <smaug____> | need to contact FB and G web devs |
| 19:15 | <rbyers> | Rather than focus on mousewheel usage, I'll probably direct my energy to getting rid of smoothscroll.js - that's much more obtainable (and valuable) in the short term I think. Now that we have smooth scrolling, it's strictly better for the page anyway. |
| 19:18 | <rbyers> | There might be a third option here though - change the spec in a way that's compatible but still better than the status quo. I'll do some research to see if I can find any other options. |
| 19:23 | <terinjokes> | tobie: looks like an update happened, but console didn't seem to make it in |
| 19:24 | <tobie> | terinjokes: yeah, I merge a manual addition to the DB minutes ago. |
| 19:24 | <terinjokes> | ah, k |
| 19:24 | <tobie> | *merged |
| 19:34 | <annevk> | TabAtkins: Notifications API iirc |
| 19:34 | <annevk> | TabAtkins: Streams? |
| 19:34 | <botie> | Streams are awesome btw, loads of fun |
| 19:35 | <annevk> | Yes |
| 19:35 | <TabAtkins> | botie, forget about Streams. |
| 19:35 | <botie> | TabAtkins, I didn't have anything matching about streams |
| 19:35 | <TabAtkins> | wtf botie |
| 19:35 | <annevk> | botie: forget streams |
| 19:35 | <botie> | annevk: I forgot streams |
| 19:36 | <tobie> | terinjokes: merged now |
| 19:37 | <Domenic> | poor botie |
| 19:38 | <Domenic> | botie, Streams are awesome btw, loads of fun |
| 19:38 | <botie> | OK, Domenic. |
| 19:38 | <annevk> | 😊 |
| 21:35 | <rbyers> | smaug____ miketaylr: Ok I'm getting a little desperate. Do you think it would be completely insane if blink were to refuse (with a console warning) to dispatch 'mousewheel' events to handlers whose function name happened to be "ssc_wheel" (at least for the next year or so until usage has dropped)? My httparchive data suggests that's always the buggy |
| 21:35 | <rbyers> | smoothscroll.js library. |
| 21:37 | <rbyers> | Not sure I really want to go down this path (IE has relied on site-compat hacks in the past, and you guys do some hacks too, right?). But it seems only 99% insane to me (especially if time-limited)... The alternative is probably to leave interop broken, or to update the specs so Firefox has to copy WebKit's crappy bug ;-) |
| 21:37 | <miketaylr> | i'm always excited about hacks |
| 21:38 | <miketaylr> | rbyers: if you can do that and get someone poplular JakeA or paul_irish_ to signal boost a blog post |
| 21:39 | <rbyers> | miketaylr: I'm doing the blog post anyway (https://plus.google.com/+RickByers/posts/RdYaYF5DTF4 for now - probably more from our DevRel). |
| 21:40 | <rbyers> | Trouble is, these sites are mostly rinky-dink wordpress sites, probably not actively maintained, etc. So I don't expect much from outreach or even console warnings. |
| 21:40 | <rbyers> | But at least doing that will make me feel less guilty when I later break the site completely ;-) |
| 21:40 | <miketaylr> | hm, yes. |
| 21:41 | <rbyers> | maketaylr: Can you point me at any details on the ugly hacks you've done for compat? You've got some site-specific stuff activated by URL, right? Anything generic like this (lots of impacted URLs copying the identical code patterns)? |
| 21:44 | <rbyers> | Seems unfair that Firefox, IE, Opera etc. get to have all the fun resorting to compat hacks for crappy sites while chromium just says "someone will notice the breakage and fix the site" <grin>. |
| 21:45 | <miketaylr> | ain't marketshare grand |
| 21:48 | <miketaylr> | rbyers: here's opera's current browser.js https://gist.github.com/anonymous/c3df94dd2c2fe8495b2f#file-browser-js-L289 |
| 21:48 | <miketaylr> | let me find some gecko stuff |
| 21:48 | <miketaylr> | this used to be much bigger in the presto days, as you might imagine |
| 21:50 | <rbyers> | Yeah that's surprisingly small |
| 21:50 | <rbyers> | Guess it was reserved only for the biggest impact stuff, eh? |
| 21:51 | <miketaylr> | yeah, hallvors could say more -- he used to maintain that at opera |
| 21:51 | <miketaylr> | unsure who does that now |
| 21:51 | <rbyers> | And looks like every rule is hostname controlled. Sad to see how much is google :-(. I'm gonna have to start serving some sites from google.rbyers.net just to mess with the rules here ;-) |
| 21:51 | <miketaylr> | heh |
| 21:55 | <miketaylr> | rbyers: here's a youtube specific hack we have to fudge the UA string in desktop https://bugzilla.mozilla.org/show_bug.cgi?id=1233970, and we also have a dynamic ua override mechanism for fennec and b2g https://dxr.mozilla.org/mozilla-central/source/mobile/android/app/ua-update.json.in |
| 21:55 | <miketaylr> | (it's not used very much, but it's handy if we need it) |
| 21:56 | <hallvors> | rbyers: the file for Presto-based Opera versions is also on GitHub, we had some generic hacks applied to libraries by file names there. |
| 21:57 | <smaug____> | rbyers: on desktop the hacks Gecko has are mostly for Google sites |
| 21:57 | <smaug____> | or perhaps even only |
| 21:57 | <smaug____> | and those are rare |
| 21:58 | <smaug____> | rbyers: I don't think we try to detect any JS function name or anything like that |
| 21:58 | <smaug____> | implementing that without regressing performance ... hmm, first detect that the problematic script is loaded |
| 21:58 | <smaug____> | and then enter to some slower code path |
| 21:59 | <smaug____> | might not be too bad |
| 21:59 | <hallvors> | rbyers: https://github.com/operasoftware/browserjs/blob/master/desktop/browserjs-12.50.js#L268 |
| 21:59 | <miketaylr> | dhtml menu scripts, hooray |
| 22:00 | <hallvors> | oh, the nostalgia ;) |
| 22:01 | <rbyers> | Heh heh, ok thanks a ton guys. |
| 22:02 | <hallvors> | well, well. Presto-Opera's User JS API was great. Really powerful for those things. |
| 22:02 | <smaug____> | hallvors: could it do something similar what rbyers tries to do here? |
| 22:02 | <hallvors> | As I told Mike directly a moment ago, I think it wrapped a log of power in a lot of simplicity |
| 22:03 | <hallvors> | smaug____: easily, starting here: https://github.com/operasoftware/browserjs/blob/master/desktop/browserjs-12.50.js#L414 |
| 22:04 | <hallvors> | a BeforeExternalScript event to inspec file names |
| 22:04 | <hallvors> | then code like the L268 I linked above to tweak variables, environment.. |
| 22:04 | <rbyers> | In my case the script is often minified - can't always rely on the script filename. See https://docs.google.com/spreadsheets/d/1P4kJfl-f5jeiKzYJyKVeo79NJEDL565Agcgl5hRh5ic/edit?pref=2&pli=1#gid=1895977753 |
| 22:04 | <hallvors> | it worked like a charm :) |
| 22:06 | <rbyers> | In my case I think I'd want to hook calls to addEventListener('mousewheel'). That shouldn't be TOO performance sensitive (adding/removing mousewheel handlers shouldn't be that common). |
| 22:07 | <rbyers> | Then consult the Function.name of the provided handler... |
| 22:07 | <hallvors> | rbyers: yeah, the web has moved on a bit - all the concatenation and obfuscation makes those old approaches less useful I guess :-/ |
| 22:07 | <hallvors> | We also had the amazing magic variables and functions: https://github.com/operasoftware/browserjs/blob/master/desktop/browserjs-12.50.js#L377 |
| 22:07 | <rbyers> | Yeah I was just looking at those |
| 22:08 | <hallvors> | Basically you could define getters that were invisible to page scripts |
| 22:08 | <rbyers> | fascinating |
| 22:08 | <hallvors> | not caught by enumeration etc |
| 22:09 | <rbyers> | Once the list of things becomes non-trivial it must be a bit of a nightmare to maintain, no? Eg. do you try to do automated testing for each rule? |
| 22:10 | <rbyers> | Are there cases where a web developers wants to fix their bug but can't without coordinating exactly with a change to browser.js? |
| 22:11 | <hallvors> | We had automated testing. |
| 22:11 | <rbyers> | I'm also worried about website testing. Developer makes some changes, verifies it works well in Chrome on their staging server, then pushes to their real URL which now triggers different behavior ;-) |
| 22:11 | <hallvors> | I do remember a case or two where we'd break the site |
| 22:11 | <hallvors> | But mostly I think that happened with UA spoofing and less with browser.js |
| 22:11 | <rbyers> | It's kind of embarassing how far ahead of us y'all are on website compat - we're noobs at this :-( |
| 22:12 | <hallvors> | I have broken Deviantart and Hotmail though, with buggy browser.js updates :-p |
| 22:12 | <smaug____> | rbyers: looking at the crbug 501568. So it works in gecko because ssc_addEvent("mousewheel", ssc_wheel); doesn't really do anything since mousewheel isn't supported? So the script tries to do something (possibly buggy) and luckily that function call doesn't make sense in case of Gecko. |
| 22:12 | <rbyers> | :-) Well it's not like we don't break major sites by accidentally shipping bugs - that I can live with :-) |
| 22:12 | <hallvors> | not sure if that is somethin you should envy ;) |
| 22:13 | <smaug____> | or perhaps unfortunately, since they would have noticed their bug perhaps earlier if it was working badly in gecko |
| 22:13 | <rbyers> | smaug____ exactly. There's also a UA check specifically for Chrome, Safari or (strangely since it never works) Firefox. |
| 22:14 | <hallvors> | VoodoJS. Summon unknown browsers with untested commands, assume something will happen. |
| 22:14 | <hallvors> | :) |
| 22:14 | <rbyers> | :-) |
| 22:16 | <rbyers> | Ok, well I've gotta run. Thanks for all the education guys. I'll do some more research on the various options. Maybe we just break all these sites - I mean 0.26% of all web pages can't be THAT many pages, can it <grin>? |
| 22:17 | <smaug____> | detecting ssc_wheel might not be too bad |
| 22:17 | <smaug____> | and warn hard when it is detected |
| 22:18 | <hallvors> | Well, breaking mousewheel scrolling isn't the worst possible breakage (if I understand the issue correctly you can still scroll by dragging scrollbars and such?) |
| 22:18 | <hallvors> | Though I must say it would be really fun if other browsers picked up the old User JS API to assist their sitefixing :) |
| 22:19 | <hallvors> | probably not going to happen, but still :) |
| 22:19 | <rbyers> | Yeah, dragging scrollbars works (though I'm sure many users won't try that) but not keyboard. |
| 22:19 | <hallvors> | TIL API nostalgia is a feeling |
| 22:19 | <rbyers> | :-) |
| 22:19 | <hallvors> | breaking keyboard scrolling *is* bad :/ |
| 22:20 | <hallvors> | IMHO.. |
| 22:20 | <rbyers> | Worse than mousewheel? Because of accessibility? |
| 22:20 | <rbyers> | In practice most users scroll with wheel... |
| 22:20 | <smaug____> | hmm, do we have data about that |
| 22:20 | <hallvors> | I think it's sort of the fallback option if wheel doesn't work.. |
| 22:21 | <hallvors> | I'd expect users to try keys |
| 22:21 | <hallvors> | but maybe it's just me ;) |
| 23:05 | <miketaylr> | are webkit layout tests safe to convert to web platform tests? cc jgraham |
| 23:05 | <miketaylr> | i don't see license info in the tests themselves |
| 23:06 | <miketaylr> | maybe just a comment "Based on a test from the WebKit project" is ok |
| 23:12 | <miketaylr> | it looks like that's the approach taken in https://github.com/w3c/web-platform-tests/commit/b4c286f4fefe5cf1f47ecdd4e1aa6f41c6ff793f |
| 23:22 | <jgraham> | miketaylr: People have done that before, but it is relicensing, so you probably need permission or something |
| 23:23 | <miketaylr> | jgraham: ok, i'll send an email to apple, unless hober wants to give me permission real quick |
| 23:24 | <miketaylr> | (or, i just write my own tests and call it a day) |
| 23:36 | <MikeSmith> | if anybody knows the current implementor consensus on HTML Imports, can you please remind me |
| 23:36 | <MikeSmith> | last I heard it was on its way out |
| 23:37 | <jgraham> | MikeSmith: Pretty sure Moz don't want to implement it |
| 23:37 | <jgraham> | Unless something changed |
| 23:37 | <MikeSmith> | jgraham: that's what I thought too |
| 23:38 | <MikeSmith> | but then in bugzilla.mozilla.org I see open bugs related to it |
| 23:38 | <MikeSmith> | e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1016888 |
| 23:38 | <MikeSmith> | so does that mean it has actually already been implemented in gecko? |
| 23:39 | <MikeSmith> | ah |
| 23:40 | <MikeSmith> | 「Firefox has no plans to support HTML imports though for now it can be enabled through the "dom.webcomponents.enabled" preference in about:config」 |
| 23:40 | <MikeSmith> | at caniuse |
| 23:41 | <Domenic> | Has everyone seen dglazkov's HTML modules |
| 23:41 | <Domenic> | re-imaging HTML imports on top of <script type="module"> |
| 23:41 | <Domenic> | I like it a lot |
| 23:41 | <Domenic> | https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md |