| 06:33 | <jochen__> | annevk: do you happen to know how / where firefox handles <a href="blob:.." download> clicks? |
| 06:33 | <jochen__> | annevk: it seems that while typically firefox navigates (and thus dispatches the onunload event), it doesn't for blob URLs? |
| 06:34 | <annevk> | jochen__: don’t; sounds like a bug |
| 06:55 | <jochen__> | is it just me, or is bugzilla really really slow? :/ |
| 06:57 | <annevk> | jochen__: I think so too |
| 07:05 | <jochen__> | k, filed a bug. best I found was nsDocShell::InternalLoad but that only skips beforeunload for javascript: URLs |
| 10:19 | <JakeA> | annevk: Little demo - https://jakearchibald.github.io/streaming-html-spec/#origin. Requires TransformStream, so I guess Chrome Canary + web platform experiments flag. Streams the whole HTML spec, but just displays the linked section. Pauses the download once it gets it. |
| 10:21 | <annevk> | JakeA: I'm not really sure how flags work, but that doesn't look like a lot of code at all |
| 10:22 | <JakeA> | annevk: chrome://flags/#enable-experimental-web-platform-features. But yeah, turned out pretty easy. Hackiest bit is having to use an iframe & document.write to do the parsing. |
| 13:53 | <wanderview> | JakeA: maybe footnotes are one of those things you have to be older to understand... like publishing |
| 14:24 | <gsnedders> | where is insertion order specified for objects in ES? |
| 14:26 | <gsnedders> | https://tc39.github.io/ecma262/#sec-enumerate-object-properties is where I'd expect it to be, but it isn't |
| 14:27 | <gsnedders> | or does for..in not require it? |
| 14:28 | <annevk> | gsnedders: "The mechanics and order of enumerating the properties is not specified but must conform to the rules specified below." |
| 14:29 | <gsnedders> | But it is that section that deals with for..in, right? |
| 14:29 | gsnedders | for some reason was convinced for..in now had a defined order |
| 14:29 | <annevk> | gsnedders: yeah, if you hover over the heading you find that the for/in section is a caller |
| 14:30 | gsnedders | hasn't touched the ES spec much since ES5 days :) |
| 14:38 | <annevk> | Properly dealing with the v0 createElement() version that took a string as a second argument is rather painful |
| 14:53 | <annevk> | Only Firefox implements customized built-in elements?! |
| 14:53 | <annevk> | I guess Chrome still hasn't shipped them or some such? |
| 14:55 | <annevk> | So many bugs everywhere |
| 15:48 | <JakeA> | wanderview: haha yeah, pretty surprised at the reaction. I got less shit for questioning frameworks. |
| 15:48 | <wanderview> | JakeA: at this point I just look forward to referencing that twitter thread in a footnote one day |
| 15:51 | <gsnedders> | tbf, I think footnotes both make sense and the way most people implement them with scrolling media is stupidly broken |
| 16:26 | <wanderview> | annevk: I'm going to do the request-url-fragment propagating in service worker interception... I think I will just do a mochitest for now while the spec is sorted... or do you think I should write it as a WPT? |
| 16:27 | <annevk> | wanderview: mochitest seems okay |
| 16:28 | <annevk> | wanderview: .tentative WPT would make my job easier |
| 16:28 | <wanderview> | annevk: what is ".tentative"? |
| 16:28 | <wanderview> | just a WPT naming convention? |
| 16:28 | <annevk> | wanderview: yeah, for things not specced |
| 16:29 | <wanderview> | annevk: cool... first I have heard of that |
| 18:17 | <annevk> | Domenic: should I rename the whatwg/dom shadow label to "topic: shadow"? |
| 18:17 | <annevk> | Domenic: I guess the main benefit would be that you can search across the entire WHATWG org for a label |
| 18:17 | <annevk> | Domenic: which seems nice |
| 18:21 | <annevk> | JakeA: DocumentFragment insertion is a tad different though and if you're inserting a lot of <script> elements maybe it can be a little faster |
| 18:22 | <annevk> | JakeA: but hopefully not in the general case... |
| 18:22 | <JakeA> | annevk: I imagine mutation events can change things too |
| 18:22 | <annevk> | JakeA: right, a lot less mutation records |
| 18:22 | <JakeA> | But like you say, not general |
| 18:25 | <Domenic> | annevk: seems like a good idea |
| 18:32 | wanderview | has to figure out WPT reftests and is sad. |
| 18:40 | <gsnedders> | wanderview: why so? |
| 18:40 | <wanderview> | gsnedders: union rules... I'm supposed to stick to the DOM |
| 18:42 | <wanderview> | gsnedders: its also partly because I have to figure out how to do svg stuff |
| 18:42 | <gsnedders> | hah, SVG stuff is fun :) |
| 18:43 | <wanderview> | gsnedders: this is what I get for reading bug reports from xidorn |
| 18:43 | <gsnedders> | wanderview: I mean I both recommend doing that and recommend against doing that. |
| 18:44 | <wanderview> | gsnedders: well, at least I vaguely know how to embed multiple things in an svg and pick them by URL fragment target now |
| 18:47 | <gsnedders> | I wonder how much would break if we made input@type=password.value always equal "" or "password" |
| 18:47 | <gsnedders> | Probably quite a lot, given plenty of sites do testing of the password strength client side. |
| 18:56 | <domfarolino> | Is it at all possible to see valid HTML tag sequences (like `<b></b>`) appear in the source of a document but not have these added to the DOM? Or will you *always* have to use escape characters to do this |
| 18:57 | <domfarolino> | Like, can I _ever_ see `<b></b>` in the source of a document, have this same sequence rendered as text and not picked up by the parser? |
| 19:05 | <domfarolino> | Ah I just found the `<xmp>`! |
| 19:06 | <domfarolino> | Though it is obsolete. I guess `<textarea readonly>` also works |
| 19:08 | <gsnedders> | domfarolino: <xmp>, <script>, <style>, <textarea>, probably more |
| 19:09 | <gsnedders> | (of course script/style depend on CSS whether they'd get rendered) |
| 19:09 | <gsnedders> | domfarolino: heck, <input type="text" value="<b></b>"> |
| 19:10 | <domfarolino> | gsnedders: Forgot the obvious `<script>` and `<style>`.. Oh wow that's interesting thanks for the example! |
| 19:19 | <gsnedders> | I'm sure there's more ways you can do this |
| 19:20 | <domfarolino> | gsnedders: Yeah now that I think of it there are a ton |
| 19:35 | <TabAtkins> | @annevk @esprehn I'm not planning on doing any work with async mutation events. Outside of my wheelhouse, and I've got way too many other things to worry about to move into something tangential like that. |
| 19:36 | <TabAtkins> | domfarolino: Note that if you're writing a Bikeshed document, you can freely use <xmp> - it'll convert to a <pre> (with contents escaped) in the output so your document validates. |
| 19:37 | <TabAtkins> | But yeah, <script style="display: block"> (or same with <style>) also works, tho they'll be active elements (so don't use <style> unless you want the CSS to work, and use <script> with a nonsense type='' attribute). |
| 19:38 | <TabAtkins> | But see https://tabatkins.github.io/railroad-diagrams/example.html for an example of using a visible <script> for useful purpose - it's showing the JS and the results of running the JS. ^_^ |
| 19:39 | <wanderview> | gsnedders: hmm... reftests are easier than I thought |
| 19:39 | wanderview | probably just jinxed himself |
| 19:44 | <domfarolino> | TabAtkins: Oh nice thanks! Just read that section in the Bikeshed document. Oh, I didn't know you could actually display a working script block; thanks for the info!! |
| 19:50 | <esprehn> | @TabAtkins: I meant you might know who owns the DOM on the chrome team :) |
| 19:50 | <TabAtkins> | Oh, that's Tokyo. |
| 19:50 | <TabAtkins> | Dunno who the *person* is. |
| 19:51 | <gsnedders> | wanderview: :) |
| 20:05 | <TabAtkins> | Don't we have a blame-annotated view of the HTML source somewhere? |
| 20:05 | <TabAtkins> | I really wanna see what commit line 93222 came from. |
| 20:06 | <gsnedders> | TabAtkins: I just use GitHub nowadays |
| 20:07 | <TabAtkins> | gsnedders: Which very specifically doesn't work for HTML, unless I'm doing something wrong? |
| 20:07 | <gsnedders> | oh wait for HTML |
| 20:07 | <gsnedders> | I've mostly justed used a local checkout, though dear god does it eat CPU |
| 20:13 | <wanderview> | is there any way to nicely use utility functions in a reftest that depend on testharness.js's step_func()? |
| 20:16 | <Domenic> | TabAtkins: there's a link in the whatwg/html readme |
| 20:16 | <Domenic> | wanderview: I always make my utility functions take a t argument |
| 20:16 | <wanderview> | Domenic: where do I get the t argument in a reftest? |
| 20:16 | <TabAtkins> | Ah, danke, I haven't actually looked at the README ever. ^_^ |
| 20:16 | <Domenic> | wanderview: oh I see, reftest specific, I skipped past that |
| 20:17 | <wanderview> | I can either make this utility function work if t is null, or rewrite the function in my reftest |
| 20:17 | <wanderview> | utility function in question is quite small... wait_for_state() in serviceworkers |
| 20:18 | <wanderview> | Domenic: maybe this is enough: const fake_test = { step_func: f => f }; |
| 20:20 | <wanderview> | that seems to work |
| 20:24 | <Domenic> | MikeSmith: lots of errors with the new JS syntax checker on some spec demos :-/. https://travis-ci.org/whatwg/streams/builds/344010078#L2276 |
| 20:25 | <Domenic> | MikeSmith: files are in e.g. https://github.com/whatwg/streams/blob/master/demos/append-child.html |
| 20:36 | <gsnedders> | wanderview: what are you trying to do? control when the screenshot is taken? |
| 20:37 | <wanderview> | gsnedders: I am writing a test that an <img src="some.svg#target"> still renders properly when intercepted by a service worker |
| 20:37 | <gsnedders> | wanderview: what do you want step_func to do? |
| 20:38 | <wanderview> | gsnedders: so I need to do some setup of the service worker.... the service worker utility function wait_for_state() takes a test object with a step_func... I just want wait_for_state() behavior |
| 20:38 | <wanderview> | stubbing the step_func seems to work |
| 20:38 | <gsnedders> | ah. um. that's awkward. Yeah, that's the only thing I can suggest. |
| 20:38 | <gsnedders> | Given including testharness.js will make ita a testharness.js test. |
| 20:38 | <wanderview> | gsnedders: here is what I ended up with: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1437760&attachment=8952500 |
| 20:38 | <mchampion> | Hmm, https://whatwg.org/workstream-policy renders the title as "WHATWG orkstream Policy" but it |
| 20:39 | <mchampion> | is correct in the source markdown. |
| 20:44 | <TabAtkins> | mchampion: You have a problem with orkstreams? |
| 20:44 | <TabAtkins> | The WHATWG policy is that ork and their streams are a-ok. |
| 20:45 | <mchampion> | A bit evil for my tastes, Hobbitstreams would be preferable |
| 20:45 | <TabAtkins> | That's racist. |
| 20:46 | <Domenic> | Oooh weird |
| 20:46 | <Domenic> | Thanks mchampion, probably my bad with recent website upgrades, will fix |
| 20:46 | <TabAtkins> | (Also, I think Tolkien used the spelling "orc"; "ork" is intended to be a 40k reference.) |
| 20:47 | <TabAtkins> | Domenic: You need to run it with -Wall to keep all the Ws, otherwise it drops some. |
| 20:47 | <Domenic> | -_- |
| 20:47 | <TabAtkins> | I'll never apologize. |
| 20:49 | wanderview | ponders which browser corresponds to each 40k race... |
| 20:50 | <Domenic> | Wow https://www.tutorialspoint.com/python/string_lstrip.htm does not do what I thought it did at all |
| 20:50 | <TabAtkins> | What did you think it would do? |
| 20:54 | <Domenic> | I thought it would basically be like a substring |
| 20:55 | <Domenic> | E.g. I thought `"ababcd".lstrip("ab")` would give `"abcd"`. But instead it gives `"cd"`. |
| 20:55 | <Domenic> | It treats the given string as an array of characters |
| 20:55 | <TabAtkins> | Oh! Yeah, it's somewhat confusing. ("abbcd" also reduces to "cd" .) |
| 20:55 | <Domenic> | right yeah |
| 20:56 | <Domenic> | It makes sense when I realized mostly it was meant to be called with no arguments |
| 20:56 | <Domenic> | (to strip whitespace) |
| 20:57 | <TabAtkins> | This is another case where treating strings as iterables obscures the behavior, rather than helps. It really should take a list or set of characters, that's *much* more clear than *treating* a string as a list. |
| 20:57 | <TabAtkins> | (I'm still strongly of the opinion that strings should never be iterable; you should have to call a specific method to get an iterable over the string.) |
| 20:58 | <TabAtkins> | (For many reasons, including that "recurse on iterables until you find something that's not iterable" requires a special case for strings *every single time*, or else you'll infinite-recurse since characters are strings too.) |
| 21:27 | <MikeSmith> | Domenic: looking at the checker results for that Streams demo now |