| 04:29 | <domfarolino> | annevk: Under the "setter" section of https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-idl-attributes, what type is the "given value" in the case elem.onclick = function(e) {...}...I imagine it is a callback object, not a raw uncompiled handler? |
| 04:56 | <domfarolino> | annevk: I believe it is, I'm just trying to find out when an event handler's value will ever be created as an internal raw uncompiled handler. That seems to be in the attribute change steps, but I expected to see these steps being called from the parser or something |
| 05:05 | <annevk> | domfarolino: setAttribute |
| 05:12 | <domfarolino> | annevk: Hm, that's for when call from script right? How about when no script is running, and the browser is just parsing <link ... onload="whereDoesThisGetParsed?"> I kinda expect something like DOM's set-attribute and set-an-attribute-value to be called at some point? |
| 05:18 | <annevk> | domfarolino: that will do so per the parser |
| 05:19 | <annevk> | domfarolino: might not all be linked up |
| 05:24 | <domfarolino> | annevk: Ok thanks |
| 05:29 | <domfarolino> | annevk: One more (unrelated to event handlers) question: in https://html.spec.whatwg.org/multipage/semantics.html#interactions-of-styling-and-scripting, we have a list of conditions that, if met, make a style sheet one that "blocks scripts". |
| 05:30 | <domfarolino> | annevk: I'd expect after a script-blocking style sheet is obtained, one of those conditions would definitely not hold, so that we can effectively decrement the number of script-blocking ss's. Is that what the purpose of the `style sheet ready` flag is? |
| 05:31 | <annevk> | Dunno offhand |
| 05:31 | <annevk> | Can check in ~2h |
| 05:32 | <domfarolino> | annevk: Regardless, it seems that if those conditions are used to determine whether a style sheet is script-blocking, it's hard to distinguish a style sheet that has successfully loaded, and thus is no longer script-blocking, from one that is. |
| 05:32 | <domfarolino> | Sure sure no worries, sorry to ping so early |
| 05:42 | <annevk> | Hmm yeah, maybe; Emilio also mentioned (somewhat related) that matching the environment requires layout for iframes and such and is therefore more fuzzy than one might expect |
| 06:48 | <domfarolino> | annevk: I'll add a comment to https://github.com/whatwg/html/pull/3544 in the morning about maybe explicitly making a style sheet non-script-blocking after it has been obtained. Yeah it would be nice to have "matching" defined (is it?) somewhere...that's a good point. Should we file an issue to harden that? |
| 06:49 | <domfarolino> | Oh, wait it is defined whoops. But yeah if that's more fuzzy than expected it might be nice to clean that up? Not sure how to though |
| 07:09 | <annevk> | Yeah, not sure either |
| 11:43 | <lgrahl> | https://discourse.wicg.io/ <-- why was I not aware of this awesome place |
| 15:51 | <domfarolino> | Domenic: Oh sorry, didn't see your latest comment on https://github.com/whatwg/html/issues/3610 before posting mine :) |
| 15:58 | <domfarolino> | (Question in my comment may help me write a test under https://github.com/web-platform-tests/wpt/tree/master/html/semantics/document-metadata/interactions-of-styling-and-scripting testing that script-blocking style sheets have their events fired before script execution) |
| 16:01 | <hoishin> | :disconnect chat.freenode.net |
| 16:07 | <annevk> | domfarolino: it seems it isn’t really defined when that flag gets set |
| 16:07 | <annevk> | domfarolino: I’d expect it to be set as part of the task dispatching the load event |
| 16:08 | <annevk> | (Forgot to look at it earlier, sorry) |
| 16:10 | <domfarolino> | annevk: Agreed, I think it could be (potentially renamed to "style sheet resolved" and) and used in https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element:critical-subresources to remove the given resource from the set of script-blocking resources |
| 16:11 | <annevk> | domfarolino: reason to rename? |
| 16:11 | <domfarolino> | "style sheet ready" very much indicates that it obtained successfully (IMO). I think it'd be nice to be more general, since even resources that were failed to obtain are at least no longer script-blocking |
| 16:12 | <annevk> | domfarolino: ah, prefer “done” then due to promises |
| 16:12 | <domfarolino> | +1 |
| 16:14 | <domfarolino> | annevk: Also if you happen to have an answer for https://github.com/whatwg/html/issues/3610#issuecomment-420322487 that would help me file a chrome bug :) |
| 16:21 | <domfarolino> | If we make the setting of the “style sheet ready/done” flag part of the task that gets fired, then of course script execution will be blocked on both obtaining the resource _and_ firing the event. But since it isn’t entirely clear (to me) when a resource becomes non-script-blocking, I can’t tell if the ordering of the fired event and script script execution is well-specified (though IMO it should be) |
| 16:21 | <annevk> | domfarolino: it depends on specifying that flag |
| 16:22 | <annevk> | domfarolino: so once that is done it’ll be the first option |
| 16:23 | <domfarolino> | thank you very much! |
| 16:57 | <zcorpan> | anyone know how to get hard line wrapping to work well in Sublime Text? |
| 17:17 | <TabAtkins> | zcorpan: You mean automatically inserting a hard line break when it auto-wraps at some column? |
| 17:32 | <zcorpan> | That would be nice, or just a keyboard shortcut to wrap the selection would be ok as well. The built-in one seems kinda broken; it doesn't collapse the indentation to a single space and it preserves existing newlines |
| 17:33 | <zcorpan> | hard wrap in TextWrangler/BBEdit worked better |
| 17:41 | <Domenic> | zcorpan: for HTML I always copy and paste text through https://output.jsbin.com/maferi . Should work on turning that logic into a Sublime plugin. |
| 17:52 | <zcorpan> | Domenic: thanks. I'll try making a plugin some day |
| 23:43 | <zcorpan> | is there something that has replaced https://wiki.whatwg.org/wiki/sanitization_rules ? |
| 23:45 | <zcorpan> | alternatively, known-good html sanitizers that follows the spec for how to parse html |
| 23:46 | <Domenic> | I think the canonical answer is https://github.com/cure53/DOMPurify |
| 23:51 | <zcorpan> | thanks |