| 00:14 | <zewt> | bleh, is there a non-pain-in-the-ass way to see which page/script is hosing Firefox these days, like some way to attach the script profiler to the browser |
| 00:15 | <zewt> | firefox is persistently in a 3-10-second-delay-per-input CPU chewing state now and I'm not sure what's causing it (and I don't really want to binary search everything) |
| 00:19 | <TabAtkins> | No task manager or equivalent in FF? |
| 00:25 | <zewt> | i think firefox is upset at my vertical tab plugin, but for reasons that look like they would take a while for me to figure out |
| 00:26 | <zewt> | triggering a slow code path or something |
| 00:34 | <zewt> | i remember why this is hard now, you can attach the inspector to the browser ... but you can't actually view things like the tab box in it (seems strange--going to the trouble of implementing a browser this way, but not making the development tools actually work on the browser. i'd think that'd be a high priority for their own work) |
| 00:38 | <birtles> | zewt: not sure if I understand your problem, but did you turn on chrome debugging? |
| 00:39 | <zewt> | yeah, I can attach to the debugger and see the tabbrowser, but the tab view itself isn't visible (which is what I think I need to fiddle with) |
| 00:40 | <zewt> | which I remember seeing a ticket for fixing the last time I tried to do something like this |
| 00:40 | <birtles> | zewt: ok, I don't know them. Does the DOM Inspector add-on do the same thing? |
| 00:40 | <birtles> | s/them/then |
| 00:41 | <zewt> | it doesn't, just restarted firefox to turn it back on (and to reset the lag; got too bad to do anything) |
| 00:42 | <zewt> | (it's a bit glitchy for those elements, which I guess is why they're hidden in the builtin tools, but better glitchy than nothing...) |
| 00:47 | <jgraham> | I think some sort of per-tab CPU monitoring is in the works |
| 00:47 | <jgraham> | Well it's a rumor I heard at least |
| 01:39 | <roc> | the Gecko profiler should solve your problem, though I admit it's not the most user-friendly tool |
| 01:45 | <zewt> | i tried it, but i think it only gave a red herring (some noise in the tabbrowser, but after a restart and things are fast again, the profile results are identical) |
| 01:47 | <roc> | that suggests the problem was in some thread that it doesn't monitor :-( |
| 01:47 | <roc> | though that wouldn't explain why it was causing laggy response to input |
| 01:48 | <zewt> | not leaping at the thought of making a debug build |
| 01:49 | <zewt> | (opening menus was taking 10-20 seconds, so I could hit it then break in the debugger and see where I end up ... but i could just land in the JS VM somewhere, heh) |
| 08:52 | <zcorpan> | roc: i'm sorry. it's high on my todo list now though |
| 08:55 | <roc> | zcorpan: it's OK. how can I help? |
| 08:57 | <zcorpan> | roc: i don't know right now. i plan to reverse engineer the impl. maybe you can give me relevant pointers to the source code? |
| 08:58 | <roc> | you shouldn't need to do that |
| 09:02 | <roc> | zcorpan: there's an email thread in www-style titled "Behavior of getBoxQuads, convert*FromNode" which I replied to with some information |
| 09:03 | <roc> | zcorpan: basically if you search for "getBoxQuads" in www-style there are several threads with issues and resolutions |
| 09:04 | <roc> | if you have any questions, ask me instead of trawling through source |
| 09:04 | <zcorpan> | roc: yep. they are "unread" in my inbox :-) |
| 09:05 | <annevk> | So memes on Twitter have it that WebRTC in the IETF will require both H264 and V8 |
| 09:29 | <zcorpan> | http://www.w3.org/TR/mixed-content/#references references a whatwg spec |
| 09:33 | <JakeA> | 2014 was the year the w3 first referenced a whatwg spec. By 2016 the machines had taken over. |
| 09:34 | <danbri> | new W3C TR style rules: all normative references to external living standards MUST blink |
| 09:39 | <annevk> | zcorpan: Fetch has no fork |
| 09:43 | <annevk> | http://open.blogs.nytimes.com/2014/11/13/embracing-https/ does this mean NYT will use TLS? |
| 10:01 | <matijs> | By the end of 2015… :) |
| 10:54 | <JakeA> | annevk: I'm looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-container.1 and wanting to make it non-window specific so we can expose it within workers. All the associated document is used for is url. I'm thinking I should swap this for associated environment settings object and rely on |
| 10:54 | <JakeA> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27146 - does that make sense or am I going in the wrong direction? |
| 10:55 | <annevk> | JakeA: makes sense |
| 10:56 | <JakeA> | Ta |
| 11:59 | <annevk> | JakeA: thanks for working on it |
| 11:59 | <annevk> | JakeA: btw, did you follow the conversation where Hixie pointed out dedicated workers should just be a client? |
| 11:59 | <annevk> | JakeA: and once navigator.serviceWorker is exposed, that makes perfect sense |
| 12:00 | <JakeA> | annevk: yep. I think my past objections were because appcache doesn't treat a dedicated worker as its own thing. But yeah, it should be its own client. |
| 12:02 | <JakeA> | annevk: Out of curiosity, what do you use to edit specs? It sounds like heresy, but given that specs are more markup than text, I almost find myself wanting some kind of higher-level editor |
| 12:05 | <annevk> | Anolis |
| 12:06 | <annevk> | Domenic has a Markdown setup I think |
| 12:06 | <annevk> | Through TabAtkins's bikeshed perhaps? |
| 12:06 | <annevk> | Study Streams repo |
| 12:18 | <JakeA> | Cheers |
| 12:22 | <JakeA> | annevk: I've defined navigator.serviceWorker's associated env settings obj as the env settings obj of the currently executing script |
| 12:22 | <JakeA> | I feel like I need a reference to "currently executing" |
| 12:22 | <JakeA> | Is there a hook for that? |
| 12:23 | <annevk> | JakeA: I think what you want to say is that a global has an associated whatever navigator.serviceWorker returns |
| 12:24 | <annevk> | JakeA: and then use the global's env settings object |
| 12:24 | <annevk> | JakeA: so that whenever a global is constructed a navigator.serviceWorker thingy is constructed to |
| 12:30 | <JakeA> | annevk: brilliant, thanks. That was all there but I was getting to env settings via script rather than global. \o/ |
| 12:52 | <Domenic> | JakeA: I still am using raw HTML through Bikeshed, but dherman and I are working on something to integrate Ecmarkdown https://github.com/domenic/ecmarkdown into it to make it easier to write and read the algorithm steps. |
| 12:54 | <JakeA> | Ohh cool. Will look into Bikeshed & keep an eye on ecmarkdown. Ta! |
| 13:02 | <smaug____> | hmm, why has the spec changed to require type="popup" and not type="context" |
| 13:03 | smaug____ | really misses some blame/annotation for the spec |
| 13:04 | <annevk> | smaug____: what spec? |
| 13:04 | <smaug____> | HTML |
| 13:04 | <annevk> | I don't know what type=popup is |
| 13:04 | <smaug____> | menu element |
| 13:05 | <annevk> | Ah |
| 13:11 | <smaug____> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html apparently |
| 13:14 | <annevk> | 'Chrome is correct, "popup" the required type value. Firefox, as usual, is ignoring the specification' lolwat |
| 13:15 | <smaug____> | yup, had to answer to that |
| 13:16 | <JakeA> | annevk: Currently we assign a serviceworker registration to documents, is env settings obj the right thing to replace document with here? |
| 13:17 | <annevk> | JakeA: I think you want global object |
| 13:17 | <annevk> | JakeA: or env settings obj, yes |
| 13:17 | <annevk> | JakeA: they should be 1:1 |
| 13:18 | <JakeA> | Cheers |
| 13:18 | <annevk> | Good rule of thumb is probably that anywhere service worker mentions document, it's wrong |
| 13:18 | <JakeA> | hah |
| 13:20 | <smaug____> | (missing the context, but the same document can be used for several globals, and a global can be used for 1 or 2 documents) |
| 14:00 | <annevk> | JakeA: I thought I'd engage a bit more in that discussion with Joel, just in case we do have to change course |
| 14:02 | <JakeA> | annevk: Cool, sounds like he's pretty sold on fixing Chrome rather than breaking the platform more |
| 15:16 | <rektide_> | can we please make event-handlers declarative? there is, as far as i am aware, no specification which can enumerate listeners |
| 15:16 | <rektide_> | :( |
| 15:17 | <rektide_> | i had a newbie i was trying to help make his codeschool life not suck |
| 15:17 | <rektide_> | https://gist.github.com/johnelliott/690905bb909347a56941 |
| 15:17 | <rektide_> | we failed |
| 15:18 | <caitp> | :'( |
| 15:19 | <caitp> | the way that problem is usually solved is to maintain a collection of listeners for a given event, eg jquery will store this collection in an element's expando |
| 15:19 | <caitp> | it's not a very good solution, but it works for them |
| 15:39 | <rektide_> | this is one of those dark dank corners of HTML that isn't at all in any way declarative |
| 15:39 | <rektide_> | it's entirely invisible imperative |
| 15:40 | <rektide_> | :'( |
| 15:40 | <rektide_> | (the reason we failed is that getEventListeners is a tool available only to debuggers, with no specification: it was something Moz implemented a long long time ago & which spread... for debuggers) |
| 15:41 | <rektide_> | (in case the problem wasn't apparent) |
| 15:48 | <TabAtkins> | Domenic: Ah, I didn't realize you were trying to integrate ecmarkdown into Bikeshed. You should let me know about these things. ^^_ |
| 15:50 | <TabAtkins> | JakeA: You should absolutely not be editting specs by hand. Use either Bikeshed or ReSpec (I prefer Bikeshed obvs). |
| 15:50 | <Ms2ger> | Use whatever isn't respec :) |
| 15:52 | <JakeA> | TabAtkins: Are you around for Chrome Dev Summit? Would be good to see your workflow. I just did a series of editing by hand and now I kinda just want to go to bed and never get up again |
| 15:56 | <TabAtkins> | I'm in the office today if that's what you're asking. |
| 16:08 | <annevk> | rektide_: what does making them declarative mean? |
| 16:12 | <TabAtkins> | JakeA: Yeah, I can show up for CDS. |
| 16:12 | <TabAtkins> | It's just over in the Quad. |
| 16:13 | <JakeA> | TabAtkins: I may pop over to your desk on Mon/Tues if I get my shit together before CDS |
| 16:15 | <TabAtkins> | JakeA: kk |
| 16:23 | <JakeA> | TabAtkins: An alternate to Kenji & Ilya's font loading rendering proposal https://github.com/KenjiBaheux/css-font-rendering/issues/11#issuecomment-63088971 |
| 18:26 | <Hixie> | zcorpan: you around? |
| 18:26 | <Hixie> | zcorpan: are you in charge of firing 'scroll' events? |
| 18:27 | <jgraham> | (that sounds much funnier than it is supposed to) |
| 18:38 | <Hixie> | if you have a WebIDL-defined callback that returns type A |
| 18:38 | <Hixie> | and the actual callback returns type B |
| 18:38 | <Hixie> | what does Web IDL say should happen? throw TypeError? |
| 18:40 | <Hixie> | looks like yes |
| 18:40 | <zcorpan> | Hixie: yeah cssom view |
| 18:42 | <annevk> | Hixie: yes it would throw |
| 18:42 | <annevk> | Hixie: note that there's a number of open bugs around callbacks and rethrowing exceptions, some depending on fixes in HTML |
| 18:44 | <annevk> | Hixie: unless it's a promise, then it'd reject, though I'm not sure if that makes sense |
| 18:45 | <annevk> | it does make sense |
| 19:02 | <Hixie> | bummer, missed zcorpan |
| 19:02 | <Hixie> | zcorpan: when you come back, i'm looking at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26839 which involves me firing 'scroll' events at a defined time, and would like to hook into your spec to do this |
| 19:45 | <gsnedders> | TabAtkins: I wonder if you could adapt some existing tagger to reasonably do POS tagging of Twitter. |
| 19:45 | <gsnedders> | TabAtkins: (assume we limit ourselves to English here) |
| 19:45 | <TabAtkins> | Never worked with one, so I dunno. |
| 19:45 | <gsnedders> | ("you" was really the generic "one" there) |
| 19:45 | <gsnedders> | most tagged corpora are done through taggers nowadays, often with human review after |
| 19:46 | <gsnedders> | but I dunno if it'll work so well with more informal language, probably containing more typos and more unknown words |
| 19:46 | <gsnedders> | I'd be skeptical? |
| 19:53 | <rektide> | annevk: making registered event handlers declarative means exposing the registered handler in the DOM |
| 19:56 | <Ms2ger> | Anyone know a spec for the enter-to-submit behaviour in forms? |
| 19:56 | <tantek> | HTML? |
| 20:05 | <Ms2ger> | tantek, where in the kitchen sink? :) |
| 21:26 | <annevk> | rektide: odd definition of declarative |
| 21:28 | <caitp> | well it's JS, it's imperative --- but they're right, it kinda sucks :) |
| 21:30 | <annevk> | inspecting event listeners kinda sucks too, so I guess it's all good |
| 23:15 | <rektide> | annevk: by 'kind of sucks' do you mean it sucks for people trying to do it, or it sucks that people try to do it? |
| 23:15 | <rektide> | people trying to inspect event emitters |
| 23:51 | <Hixie> | why do we have a cancelAnimationFrame()? |
| 23:51 | <Hixie> | is that for the times where waiting 16ms is just too long? |
| 23:53 | <rektide> | it could be a very long time if the display is off or with dynamic refresh |
| 23:53 | <zewt> | if you want to shut something down synchronously you don't want to leave things that'll be fired in the future |
| 23:53 | <rektide> | release handles to assets early, release handles to assets often |
| 23:54 | <zewt> | if you have a "startRendering()/stopRendering()" api you don't want stopRendering to have to keep track of whether it needs to ignore the next frame (and then remember to not ignore it anymore if startRendering is called before it) |
| 23:55 | <zewt> | today's web goal: getting rid of autocomplete=off. tomorrow's goal: getting rid of target=_blank |
| 23:55 | <zewt> | (if only) |
| 23:56 | <rektide> | if we can land a robot on a comet, we can get rid of the worst target on the web. |
| 23:57 | <zewt> | i guess a more practical solution would be tab scoping, so windows opened by a tab appear as a secondary row of tabs inside that tab |
| 23:57 | <zewt> | which would make it less obnoxious without actually breaking things |
| 23:58 | <zewt> | i had a coworker ask how to make it so it always opens a window and never a tab :( |