| 00:28 | <smaug____> | jsbell: Entry webkitGetAsEntry(); that webidl doesn't allow returning null, but the prose says null can be returned |
| 00:28 | <smaug____> | so Entry -> Entry? |
| 01:23 | <Domenic> | callback interfaces are icky |
| 01:23 | <Domenic> | but if this is a legacy API then what can you do |
| 08:27 | <hsivonen> | annevk: earlier I was looking for CC0 test cases for the Encoding Standard. Now there are some: https://github.com/hsivonen/encoding_rs/commit/186ab87b68a6cd1eb3fa4895ce6dc87c66f11cf8 |
| 12:53 | <aleray_> | hi, using html5lib, when I run `html5lib.parseFragment(myhtml, treebuilder="lxml")` I get a list of Element, rather than an ElementTree. Is it normal? |
| 13:08 | <MikeSmith> | gsnedders: ⬆ |
| 13:41 | <nox> | aleray_: I think so. |
| 13:42 | <nox> | aleray_: https://html.spec.whatwg.org/multipage/syntax.html#parsing-html-fragments |
| 13:42 | <nox> | Cf. step 14. |
| 14:07 | <aleray_> | nox, thanks |
| 14:28 | <aleray_> | nox, lxml html5parser seems todo it "by hand": https://github.com/lxml/lxml/blob/master/src/lxml/html/html5parser.py#L95 |
| 15:42 | <JakeA> | Domenic: https://html.spec.whatwg.org/multipage/webappapis.html#dom-createimagebitmap - the only step that's in parallel here is resolving the promise. Does this mean the promise is kinda pointless and the work will be on the main thread? |
| 15:43 | <JakeA> | Eg steps 10 & 11 |
| 17:19 | <Domenic> | JakeA: hah, yes, looks like a bug. |
| 17:20 | <JakeA> | Domenic: cheers, will write it up |
| 17:20 | <Domenic> | I wonder where implementations actually go to be "in parallel" |
| 17:20 | <Domenic> | seems like there could be race conditions depending... |
| 17:20 | <Domenic> | or maybe there's a copy of the incoming data made at the top of the algorithm? |
| 17:20 | <gsnedders> | aleray_: yeah, there's no way to give a fragment as a tree, because you essentially have multiple top-level eleemnts |
| 17:22 | <JakeA> | Domenic: pretty early. I think the intention is for decoding & raster to happen in another thread if the input is blob |
| 17:23 | <Domenic> | I'll be curious what junov says... |
| 17:23 | <Domenic> | Is the idea that the promise-returning only matters for the blob input? |
| 17:24 | <Domenic> | so for img/video/etc. cases we should just collapse them into "Return a new promise resolved with ..."? |
| 17:26 | <JakeA> | Domenic: I'd love it if we could do SVG rasterizing in another thread. That means it should be done for <img> too, since the resize operation means the SVG needs to be re-rastered. |
| 18:18 | <Domenic> | Can someone check to see if Gecko uses the replace argument to window.open? smaug____? |
| 18:19 | <smaug____> | Domenic: you mean if that is implemented? |
| 18:19 | <Domenic> | smaug____: yeah |
| 18:19 | <smaug____> | (in a meeting but will check after that) |
| 18:19 | <Domenic> | thanks! |
| 18:32 | <Domenic> | smaug____: nevermind, I was able to test. |
| 18:50 | <smaug____> | Domenic: back |
| 18:51 | <smaug____> | the outcome was? |
| 18:51 | <smaug____> | aha, I see the github email |
| 18:53 | <smaug____> | Domenic: did you test document.open case |
| 18:53 | <jsbell> | smaug____: Entry? change made |
| 18:53 | <Domenic> | smaug____: ah right good point |
| 18:53 | <smaug____> | jsbell: thanks |
| 18:53 | <smaug____> | Domenic: since IIRC Gecko supports replace in document.open |
| 18:54 | <Domenic> | smaug____: Chrome's bindings for document.open() literally do dynamic dispatch to window.open() O_o |
| 18:54 | <jsbell> | almost missed that; did I miss anything else? (also, bugs welcome!) |
| 18:54 | <Domenic> | to be fair that does seem to be what the spec implies |
| 18:54 | <smaug____> | we do something similar... reading some code |
| 18:54 | <Domenic> | smaug____: yeah looks like document.open()-as-window.open() does not support replace either http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4321 |
| 18:55 | <smaug____> | yes, http://searchfox.org/mozilla-central/source/dom/html/nsHTMLDocument.cpp#1396 |
| 18:55 | <Domenic> | Hmm that XXXbz means maybe we should ping bz |
| 18:55 | <smaug____> | Domenic: and see bz' comment about ignoring replace there |
| 18:58 | <smaug____> | Domenic: well, bz just added the comment in somewhat unrelated patch: https://hg.mozilla.org/mozilla-central/rev/f870d9cd5af1#l1.519 |
| 18:59 | <smaug____> | he split the Open() method to two, one dealing with non window-opening case and other for window opening |
| 18:59 | <Domenic> | oh i see |
| 19:02 | <smaug____> | Domenic: and the non-window opening case certainly does care about replace param, but that is about different replace param. http://searchfox.org/mozilla-central/rev/5a3efff7dee9d3233f532126afdbcb82ffcc1ff4/content/html/document/src/nsHTMLDocument.cpp#1672-1677 http://searchfox.org/mozilla-central/source/dom/webidl/HTMLDocument.webidl#36,38 |
| 19:03 | <Domenic> | yeah exactly |
| 19:03 | <Domenic> | nice and confusing |
| 19:03 | <Domenic> | i mostly just don't want to remove this thing if someone was planning on implementing it soon |
| 19:04 | smaug____ | doesn't even know what replace does in window.open |
| 19:05 | <Domenic> | we broke the spec without realizing it |
| 19:05 | <Domenic> | but it was meant to cause window.open() to navigate the named window with replacement instead of normally |
| 19:05 | <Domenic> | so instead of fixing the spec i figure we should just remove it |
| 19:56 | <aleray_> | gsnedders, Hi |
| 19:57 | <aleray_> | thanks, I though there war a createParent option (orsomething like this) to address that |
| 19:57 | <aleray_> | *was |
| 19:59 | <aleray_> | In https://html5lib.readthedocs.io/en/latest/html5lib.html?highlight=parsefragment#html5lib.__init__.HTMLParser.parseFragment |
| 19:59 | <aleray_> | the "container" option |
| 21:30 | <jsbell> | TabAtkins: updated bikeshed, getting "Unknown Status 'ED' used." Any guesses what's bogus in my metadata? |
| 21:31 | <jsbell> | https://github.com/w3c/FileAPI/blob/gh-pages/index.bs for reference |
| 21:32 | <TabAtkins> | jsbell: Nothing's bogus, it's a semi-breaking update that'll flush out some minor fixes in some places. The W3C statuses are now limited to groups that I know are W3C groups. |
| 21:33 | jsbell | assumes https://github.com/tabatkins/bikeshed/commit/f02935307493078ab95b09236b27d2f471aebb44 ... ah |
| 21:33 | <jsbell> | TabAtkins: Group: webplatform in this case |
| 21:33 | <TabAtkins> | Yes, not known yet. Gimme a sec. |
| 21:34 | <jsbell> | Cool, found megaGroups = { ... } |
| 21:34 | <TabAtkins> | I need to make it friendlier, so if there's no name clash I go ahead and let you use it for an unknown group, but throw a warning asking you to let me know about it. |
| 21:35 | <TabAtkins> | Okay, update pushed. |
| 21:35 | <jsbell> | yay, works |
| 21:36 | <TabAtkins> | You'll also start getting priv-sec nagging. ^_^ |
| 21:36 | <jsbell> | yep, ignoring it in FileAPI (not my spec...) |