| 05:24 | <annevk> | Woohoo, clean merge |
| 05:28 | <MikeSmith> | annevk: big patch? |
| 05:28 | MikeSmith | checks the commit log |
| 05:28 | <annevk> | MikeSmith: nah it was simple, but it's properly linked to the PR and the PR appears purple |
| 05:28 | <MikeSmith> | hmm did you push it already? |
| 05:29 | <MikeSmith> | commit log has "annevk authored 13 hours ago" |
| 05:29 | <annevk> | MikeSmith: I just pushed it though |
| 05:29 | <MikeSmith> | ah yeah OK |
| 05:29 | <MikeSmith> | yeah that shows when you committed it, that timestamp |
| 05:30 | <annevk> | 13h ago it was not Sep 2 here :-) |
| 05:32 | <MikeSmith> | nice work on all those patches |
| 05:32 | <MikeSmith> | and nice work on whittling away at the W3C bugs |
| 05:32 | <MikeSmith> | https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=59308&product=WHATWG&resolution=--- now at 334 bugs |
| 05:34 | <MikeSmith> | though the curve on the open is now way bent toward "this is not going to be easy or quick to resolve" bugs |
| 05:34 | <MikeSmith> | *on the open bugs is now |
| 05:36 | <annevk> | Yeah, so I'd like to actually make a collection of somewhat easy-to-fix bugs if there are any left. Through Mozilla I can get funding for an Outreachy intern (and meanwhile we try to figure out how to get diversity grants done right) and I thought a good project might be submitting patches to the HTML Standard |
| 05:36 | <MikeSmith> | annevk: I notice that https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821 already has a PR (though against the W3C fork) |
| 05:36 | <MikeSmith> | annevk: oh |
| 05:36 | <MikeSmith> | cool to hear that you got funding for somebody to help |
| 05:37 | <MikeSmith> | as far as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821 maybe we could ask that commenter (Scott Beardsley) to re-submit that patch against the https://github.com/whatwg/html sources |
| 05:38 | <MikeSmith> | OK if I comment on that bug to say as much? |
| 05:38 | <annevk> | MikeSmith: oh sorry, I just did |
| 05:38 | <MikeSmith> | ah ok |
| 05:38 | <MikeSmith> | no worries |
| 05:39 | <annevk> | MikeSmith: since I guess it has to be said, feel free to comment on any bug as you wish, and continue to feel free to resolve them too |
| 05:39 | <annevk> | :-) |
| 05:39 | <MikeSmith> | ah okk |
| 05:45 | <MikeSmith> | I wonder what problem for Web users and Web developers in practice the Alliance for Open Media thing is actually going to solve without Apple on board |
| 05:46 | <MikeSmith> | roc: ↑ |
| 05:46 | <MikeSmith> | after reading http://aomedia.org/press-release/alliance-to-deliver-next-generation-open-media-formats/ |
| 05:46 | <MikeSmith> | and https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/ |
| 05:47 | <roc> | well, it's not clear Apple won't get on board. |
| 05:47 | <MikeSmith> | ah ok |
| 05:47 | <roc> | I mean, I don't know anything |
| 05:48 | <MikeSmith> | I guess I would assume that they would have delayed the announcement if they thought Apple was going to be getting on board in the near term |
| 05:48 | <MikeSmith> | but yeah it's not productive to speculate |
| 05:49 | <roc> | the timing of the announcement was driven by external factors not related to Apple |
| 05:49 | <MikeSmith> | ah OK |
| 05:50 | <MikeSmith> | well it's clearly a really good thing |
| 05:50 | <roc> | If the AOM achieves its goals of bringing an unencumbered video codec to market, and Netflix, Amazon and Google follow through by supporting it in their respective video services, then that would be pretty great for software freedom |
| 05:50 | <MikeSmith> | absolutely |
| 05:50 | <roc> | and leave Apple and other client holdouts in a difficult position |
| 05:50 | <MikeSmith> | yup |
| 05:51 | <roc> | we can assume Netflix, Amazon and Google would not also support HEVC (or what's the point of AOM?) |
| 05:51 | <MikeSmith> | having Amazon on board with it is pretty big |
| 05:51 | <MikeSmith> | yeah |
| 05:51 | <roc> | so you'd have a situation where watching video on an iPhone takes twice the bandwidth of using any other device |
| 05:52 | <roc> | unless you bought it through iTunes I guess |
| 05:52 | <MikeSmith> | hmm |
| 05:52 | <roc> | how long would Apple tolerate that? |
| 05:52 | <MikeSmith> | yeah that's a pretty big "unless", given the state of things |
| 05:52 | <MikeSmith> | I dunno |
| 05:53 | <roc> | so I don't think Apple holding out is really relevant at all. |
| 05:53 | <MikeSmith> | how long to Apple users tolerate the fact that they don't have the freedom to install whatever browser/browser-engine they want on their iPhone? |
| 05:54 | <MikeSmith> | *how long have/will Apple users tolerated |
| 05:54 | <roc> | Apple's position is that you use apps instead, which kind of works |
| 05:54 | <MikeSmith> | for some definition of "kind of" |
| 05:54 | <roc> | but there's no getting around higher data charges for Netflix and Youtube |
| 05:54 | <MikeSmith> | yeah sure |
| 05:55 | <roc> | if you're looking for pessimistic spin on AOM, it's that maybe Netflix, Amazon, and Microsoft are just looking for bargaining leverage against the HEVC licensors |
| 05:55 | <MikeSmith> | but I can imaging Apple working with Netflix to get something special arranged |
| 05:55 | <MikeSmith> | oh |
| 05:55 | <roc> | Apple can't really do anything to fix the HEVC licensing situation for Netflix |
| 05:55 | <MikeSmith> | well I wasn't looking for a pessimistic spin on it :) |
| 05:55 | <MikeSmith> | ok |
| 05:57 | <annevk> | roc: doesn't Netflix do H265 for 4K? Or can you do that using H264 too? |
| 05:58 | <roc> | you sure can |
| 05:58 | <roc> | it's more bandwidth |
| 05:59 | <roc> | Netflix was in the H.265 camp, which is why this AOM announcement is big news. |
| 06:02 | <roc> | I assume the H.265 licensing disaster has spooked them. |
| 06:05 | <annevk> | Well, hopefully it works out |
| 06:06 | <roc> | I hope it works out with us winning |
| 06:06 | <annevk> | Me too, but I'm still somewhat scarred by the WebM experiment |
| 06:07 | <roc> | what about it? |
| 06:10 | <annevk> | roc: well I was all excited back then too about open media having a chance yet here we are with H264 mandated in practice |
| 06:10 | <roc> | yes |
| 06:10 | <roc> | things have changed |
| 06:11 | <roc> | one big advantage we have this time around is that there is a pretty-good video codec with hardware support everywhere: H.264 |
| 06:11 | <terinjokes> | is there any information on how AOM intends to do this? leveraging Thor? |
| 06:11 | <annevk> | terinjokes: from the post "We believe that Daala, Cisco’s Thor, and Google’s VP10 combine to form an excellent basis for a truly world-class royalty-free codec." |
| 06:11 | <roc> | I imagine the plan is to come up with something that's a combination of Daala, Thor and VPx |
| 06:12 | <roc> | it depends on who's serious |
| 06:12 | <terinjokes> | annevk: reading comprehension failed. sorry |
| 06:12 | <roc> | Microsoft has some good codec expertise, but it's unclear how enthusiastic they really are |
| 06:13 | <roc> | annevk: the other thing is the H.265 licensing mess. If H.265 licensing was just like H.264s AOM wouldn't be happening. |
| 06:13 | <annevk> | From Twitter it seems they're plenty enthusiastic, but that doesn't tell you much |
| 06:14 | <annevk> | roc: are you afraid the H265 camp will make a counteroffer? |
| 06:14 | <roc> | it's possible that some AOM members are in with that as their goal |
| 06:15 | <roc> | the good news for us is that there isn't an "H.265 camp" |
| 06:15 | <roc> | there are at least two warring camps |
| 06:15 | <roc> | maybe more considering I've heard 1/3 of H.265 patent holders haven't committed to MPEG-LA or HEVC Advance yet. |
| 06:16 | <MikeSmith> | wow |
| 06:16 | <roc> | if HEVC Advance lower their pricing structure to similar to MPEG-LA's, then HEVC loses its reason to exist |
| 06:16 | <roc> | and organizations like to exist |
| 06:17 | <roc> | it gets even more amusing considering all the HEVC hardware that's shipping, e.g. iPhone 6 |
| 06:17 | <roc> | that momentum was great for HEVC ... except that now those vendors have no idea how much royalties they'll have to pay *for hardware they've already shipped* |
| 06:22 | <MikeSmith> | one would hope that realization that anybody actually rational would have at this point is: Patent pools are horrible. |
| 06:22 | <MikeSmith> | *non-RF patent pools |
| 06:35 | <MikeSmith> | annevk: is it valid to do Access-Control-Allow-Headers: * |
| 06:35 | <annevk> | MikeSmith: no |
| 06:35 | <MikeSmith> | with the wildcard I mean? |
| 06:35 | <MikeSmith> | yeah, OK |
| 06:35 | <MikeSmith> | thought so |
| 06:35 | <MikeSmith> | thanks |
| 06:36 | <MikeSmith> | roc: dunno about your music tastes but your countryman Marlon Williams is great http://www.marlonwilliams.co.nz/ (/me is listening to "Dark Child") and I would go see his live show if lived nearby |
| 06:36 | <annevk> | Now I wonder what iPhone 6s will ship with |
| 06:37 | <MikeSmith> | Auckland Oct 15 http://www.marlonwilliams.co.nz/show/holy-trinity-auckland-the-church-tour-with-delaney-davidson-tami-neilson-barry-saunders/ |
| 06:37 | <MikeSmith> | annevk: video support you mean? |
| 06:38 | <annevk> | MikeSmith: yeah, if they will continue to ship hardware that will make them pay |
| 06:38 | <MikeSmith> | ah |
| 06:38 | <annevk> | That would be an interesting indicator of where Apple stands, though perhaps iPhone 6s is too baked/soon to speculate |
| 06:40 | <MikeSmith> | yeah I would think too baked but who knows |
| 06:40 | <MikeSmith> | anyway, speculating his hard! let's land patches! |
| 06:42 | <MikeSmith> | annevk: so just looking at things from a webdev PoV, where does a webdev go learn that Access-Control-Allow-Headers can't be wilcard? |
| 06:42 | <annevk> | MikeSmith: https://fetch.spec.whatwg.org/#http-new-header-syntax is pretty clear |
| 06:42 | <MikeSmith> | annevk: https://fetch.spec.whatwg.org/#http-new-header-syntax |
| 06:43 | <MikeSmith> | annevk: yeah I don't think it's clear enough to the average webdev |
| 06:43 | <annevk> | MikeSmith: hmm, although token does include * |
| 06:43 | <MikeSmith> | oh |
| 06:43 | <MikeSmith> | hmm |
| 06:43 | <annevk> | So I guess it's allowed, but * matches a header name? |
| 06:43 | <annevk> | Rather than act as a wildcard... |
| 06:43 | <MikeSmith> | oh |
| 06:43 | <MikeSmith> | that makes sense |
| 06:43 | <MikeSmith> | but it's not intuitive |
| 06:43 | <annevk> | https://fetch.spec.whatwg.org/#http-access-control-allow-headers is also pretty clear that it only allows headers to be listed |
| 06:44 | MikeSmith | looks |
| 06:44 | <MikeSmith> | well, with all due respect, I don't consider that to be pretty clear |
| 06:45 | <MikeSmith> | but maybe I'm trying to think too lowest-common-denominator |
| 06:45 | <MikeSmith> | as far was what's clear to the average dev |
| 06:45 | <MikeSmith> | but anyway I wasn't really criticizing the spec on this |
| 06:45 | <MikeSmith> | it should be clear in other places, like MDN |
| 06:46 | <annevk> | MikeSmith: I'm happy to take PRs |
| 06:46 | <MikeSmith> | and yeah I know I can update the MDN pages myself to make it more clear |
| 06:46 | <MikeSmith> | annevk: k |
| 06:46 | MikeSmith | is just kvetching at this point |
| 06:46 | <annevk> | heh |
| 06:46 | <annevk> | I'm happy to make improvements |
| 06:47 | <MikeSmith> | annevk: I think you know already that IMHO the spec isn't the best place to try to make things clear for authors |
| 06:48 | <MikeSmith> | especially if what's added is distracting/noisy to implementors |
| 06:48 | <MikeSmith> | *specs in general are the best place |
| 06:48 | <annevk> | Have to strike some balance; e.g., I'd like you to be able to understand |
| 06:48 | <MikeSmith> | sure |
| 06:48 | <MikeSmith> | fair enough |
| 06:48 | <MikeSmith> | but in my case I'm just lazy |
| 06:49 | <MikeSmith> | that said, I guess many others are equally lazy |
| 06:49 | <MikeSmith> | but we shouldn't optimize for laziness |
| 06:52 | <MikeSmith> | annevk: it is accurate to say that Access-Control-Allow-Origin is the *only* header that allows a wildcard? |
| 06:52 | <MikeSmith> | *is it accurate |
| 06:53 | <MikeSmith> | *sometimes allows a wildcard |
| 06:53 | <annevk> | of the Access-Control-* headers, yes |
| 06:53 | <MikeSmith> | k |
| 06:53 | <MikeSmith> | thanks |
| 06:54 | <terinjokes> | also worth noting that there's no list syntax for Access-Control-Allow-Origin, as a coworker found out the end of the last week |
| 07:48 | hsivonen | finds a bug in the big5 encoder algorithm |
| 07:58 | <hsivonen> | filed as https://github.com/whatwg/encoding/issues/9 |
| 08:00 | <annevk> | terinjokes: folks keep getting confused by that |
| 08:00 | <annevk> | terinjokes: the original specification allowed space-separated origins, but they were for redirects, not anything like allowing multiple origins... |
| 08:02 | <annevk> | hsivonen: could you take a look at https://github.com/whatwg/html/pull/66? |
| 08:05 | <hsivonen> | annevk: reviewing now |
| 08:19 | <zcorpan> | ok one step towards fixing web-apps-tracker https://gist.github.com/zcorpan/5f0e36efdd35b800a6be |
| 08:20 | <annevk> | I'm using [good first bug] in the whiteboard to annotate bugs for potential interns |
| 08:20 | <annevk> | Please don't fix them :-) |
| 08:20 | <annevk> | zcorpan: so... |
| 08:21 | <annevk> | zcorpan: you know web-apps-tracker uses the git repository right? |
| 08:21 | <annevk> | zcorpan: it should be easier than that |
| 08:21 | <annevk> | zcorpan: it finds the git commit by searching for the SVN ID embedded in it |
| 08:21 | <annevk> | s/ID/revision/ |
| 08:22 | <annevk> | zcorpan: though I guess we could use this for a .htaccess file |
| 08:22 | <annevk> | zcorpan: which seems nice due to its staticness |
| 08:22 | <zcorpan> | annevk: yeah. seems pointless to parse the gitlog every time when it's a fixed list |
| 08:22 | <annevk> | carry on :-) |
| 08:23 | <mkwst> | annevk: What is Body::json supposed to return for a Request object? |
| 08:23 | <zcorpan> | do we want to redirect the old urls with query strings? |
| 08:23 | <annevk> | mkwst: {} I suspect |
| 08:24 | <annevk> | mkwst: oh wait, you're not talking about the JSON serializer thingie |
| 08:24 | <mkwst> | I'm talking about the body mixin. |
| 08:24 | <annevk> | mkwst: request.json() returns the body of the request as a JSON object |
| 08:24 | <mkwst> | Ok, so if the body doesn't parse as JSON, it just explodes. |
| 08:24 | <annevk> | zcorpan: yes |
| 08:25 | <annevk> | mkwst: SyntaxError, iirc |
| 08:25 | <mkwst> | annevk: right. SyntaxExplosion. :) |
| 08:25 | <annevk> | mkwst: maybe in Chrome :-P |
| 08:25 | <mkwst> | annevk: Does Firefox implement the `formData` method? Chrome apparently doesn't. |
| 08:26 | <annevk> | mkwst: it might not |
| 08:26 | <mkwst> | ok. interesting. |
| 08:28 | <mkwst> | are these methods intended to allow casting? like, if I do `new Request(..., { body: formDataObject });`, I can get the encoded data back via `text()`. Should I be able to get the original FormData back via `formData()`? Should I get a blob via `blob()`? |
| 08:28 | <mkwst> | Or are they meant to only work when their type was passed in as RequestInit::body? |
| 08:29 | <mkwst> | (Sorry, these are stupid questions.) |
| 08:30 | <annevk> | mkwst: "casting" should work |
| 08:31 | <annevk> | mkwst: no worries; if you couldn't tell from reading the specification, perhaps we should add some examples... |
| 08:31 | <annevk> | mkwst: speaking of which, if you want to make more PRs... |
| 08:31 | <mkwst> | annevk: hey! let me finish my specs before making me work on yours. :) I'm busy "improving" fetch and XHR via the magic of monkey patches. |
| 08:36 | <hsivonen> | annevk: review done |
| 08:36 | <annevk> | hsivonen: thank you, those comments look great |
| 08:54 | <mkwst> | annevk: (Sorry, more opaque FormData questions.) Would you be sad if it wasn't possible to construct a `Request` object from JavaScript using a RequestInit object whose `body` was an opaque FormData? That is, `fetch(..., { body: oFD, ... })` would work, but `new Request(..., { body: oFD, ... })` wouldn't? |
| 08:55 | <mkwst> | annevk: it doesn't look like the former would expose the Request object to JavaScript, which means we wouldn't have to monkey patch Request to deny external access to the data while allowing internal access. |
| 08:56 | <annevk> | mkwst: the former uses new Request() literally so I'm not sure how you'd monkey patch your way out of that... |
| 08:57 | <mkwst> | Request(): 1. If opaque, reject. 2. Call InternalRequest(). InternalRequest(): [copy/paste the existing Request()]. :) |
| 08:58 | <mkwst> | basically split the construction algorithm out into "construct a Request object", and have the IDL constructor do the opacity check. |
| 08:59 | <annevk> | mkwst: so how would this work with the Cache API? |
| 08:59 | <annevk> | mkwst: if you do cache.add(url, {body:oFD}) and then enumerate the requests? |
| 09:00 | <mkwst> | Cache works on Responses, doesn't it? |
| 09:00 | <annevk> | mkwst: it stores both |
| 09:01 | <mkwst> | Where is this defined? Service Worker? |
| 09:03 | <mkwst> | if Cache is only available in Service Worker, then I don't think we need to care since the credential isn't available in the SW context. |
| 09:03 | <annevk> | Cache is everywhere |
| 09:03 | <mkwst> | but I take your point. Request data is exposed all over the place. Ugh. |
| 09:04 | <annevk> | Hmm yeah, speaking of which, we'll have a fetch observation API at some point, that'll also expose the Request object |
| 09:04 | <mkwst> | ... |
| 09:05 | <annevk> | mkwst: https://github.com/whatwg/fetch/issues/65 |
| 09:05 | <mkwst> | Can I call for a moratorium on new Request exposure? :) |
| 09:06 | <annevk> | That's easy, denied! |
| 09:06 | <mkwst> | you're mean. |
| 09:08 | <mkwst> | skimming Fetch, it's not clear whether Request exposes 'forbidden' header values. does it? |
| 09:09 | <mkwst> | it stops sets and deletes, but not gets, apparently. |
| 09:10 | <annevk> | mkwst: they won't be in there |
| 09:10 | <annevk> | mkwst: forbidden headers are set post service workers |
| 09:11 | <annevk> | just before the network |
| 09:50 | <smaug____> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25897 is a 'good first bug' ? |
| 09:50 | <smaug____> | from implementation point of view that is very tricky one |
| 09:50 | <smaug____> | what if focusin/out do something unexpected... |
| 09:51 | <annevk> | smaug____: I wasn't sure about that one, the comments suggested it was just going to be firing some more events |
| 09:51 | <annevk> | smaug____: could you maybe add a comment and clear the whiteboard? |
| 09:51 | <smaug____> | k |
| 09:52 | <annevk> | thank you |
| 09:59 | <MikeSmith> | bravo StackOverflow. One of the Free Pascal devs actually posted an answer to the SO question I posted about the compiling/linking problem I ran into when trying to compile the wattsi code to do the HTML spec build |
| 09:59 | <MikeSmith> | http://stackoverflow.com/a/32349608/441757 |
| 09:59 | <MikeSmith> | "strictly the original source is buggy" |
| 10:00 | <MikeSmith> | I won't tell Hixie that he said that |
| 10:01 | <MikeSmith> | they still have a bug to fix in their compiler on OSX though |
| 10:03 | <MikeSmith> | oh they already responded to that |
| 10:04 | <MikeSmith> | http://bugs.freepascal.org/view.php?id=28588 |
| 10:04 | <MikeSmith> | 「The "fpc" binary on OS X always has and for the foreseeable future always will generate 32 bit code by default (both on Intel and PowerPC systems). If you want 64 bit code, use "fpc -Px86_64" or ppcx64. |
| 10:09 | <annevk> | 30 bugs https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&product=WHATWG&status_whiteboard=[good first bug]&status_whiteboard_type=substring |
| 10:09 | <annevk> | seems like a good start |
| 10:13 | <hsivonen> | do I understand correctly that the HTML spec switch from a build tool written in Python (anolis) to a build tool written in Free Pascal (wattsi) and in order to make the switch, Hixie implemented infrastructure like UTF-8 strings, HTML parsing and JSON parsing in Free Pascal? |
| 10:13 | <hsivonen> | s/switch/switched/ |
| 10:14 | <annevk> | hsivonen: I think so |
| 10:15 | <hsivonen> | annevk: I see. Not a development paths I'd have recommended. |
| 10:15 | <hsivonen> | If you rewrite the world, do it in Rust. |
| 10:16 | <annevk> | That would be pretty cool, something like Bikeshed, but in Rust, so it's fast |
| 10:17 | <annevk> | I suppose eventually Rust will have enough infrastructure to port certain things |
| 10:18 | <MikeSmith> | annevk: thanks for doing https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&list_id=59317&product=WHATWG&status_whiteboard=%5Bgood%20first%20bug%5D&status_whiteboard_type=substring |
| 10:18 | <MikeSmith> | hsivonen: yeah your summary is correct |
| 10:18 | <jgraham> | Well Rust already has UTF8 strings, HTML Parsing and JSON parsing |
| 10:19 | <MikeSmith> | I agree that if somebody were to write something like this now, Rust would seem like the better way to do it |
| 10:19 | <MikeSmith> | but, well, soembody else didn't write it |
| 10:20 | <jgraham> | I think mostly Hixie used free pascal because he likes pascal |
| 10:20 | <MikeSmith> | and the wattsi code is actually pretty nice |
| 10:20 | <MikeSmith> | yeah, and he writes pascal pretty good, as far as I can see |
| 10:20 | <MikeSmith> | wattsi seems very fast to me |
| 10:21 | <jgraham> | (but also because http://ian.hixie.ch/programming/ which is not a great approach to picking a programming language) |
| 10:21 | <MikeSmith> | for what it's doing |
| 10:22 | <MikeSmith> | jgraham: you mean, just ranking the language by where the first letter of their name occurs in alphabetical order? |
| 10:22 | <MikeSmith> | I kind of like that ranking |
| 10:22 | <MikeSmith> | just don't know if it's reverse-sorted |
| 10:23 | <jgraham> | :p |
| 10:23 | <MikeSmith> | but I choose to assume it's from worst to best |
| 10:23 | <MikeSmith> | heh :) |
| 10:23 | <MikeSmith> | anyway, it puts Python at the top! |
| 10:23 | <MikeSmith> | or else C |
| 10:23 | <jgraham> | And Rust would be even topper |
| 10:23 | <MikeSmith> | yes! |
| 10:23 | <MikeSmith> | it really works! |
| 10:24 | <MikeSmith> | I'm going to inject Rust into that page |
| 10:24 | <MikeSmith> | since Hixie is serving it insecurely |
| 10:24 | MikeSmith | goes back to trying to write a wattsi patch |
| 10:28 | <hsivonen> | Hixie's Programming Languages page seems wrong about Java when it claims no language support for enumeration |
| 10:29 | <hsivonen> | also weird that Automatic memory management is colorless but Execution makes a value judgment against VMs |
| 10:29 | <jgraham> | I think the more fundamental wrongness is judging a language as a checklist of features |
| 10:30 | <hsivonen> | that, too |
| 10:30 | <Ms2ger> | Does the checklist have UTF8 strings, HTML Parsing and JSON parsing? :) |
| 10:33 | <nox> | Where is that? |
| 10:33 | <nox> | Sounds fun. |
| 10:33 | MikeSmith | learns how to disable runtime range checks in Free Pascal |
| 10:33 | <nox> | Oh god. |
| 10:33 | <nox> | So horrible. |
| 10:33 | <MikeSmith> | heh |
| 10:35 | <nox> | jgraham: And Rust's HTML parsing improved quite a bit yesterday. :) |
| 10:36 | <jgraham> | nox: Oh? |
| 10:37 | <nox> | jgraham: 10 PRs landed, h5e even parses <isindex> now. |
| 10:37 | <jgraham> | Nice! |
| 10:41 | <annevk> | Another clean merge |
| 10:44 | MikeSmith | peruses the commit log |
| 11:12 | <annevk> | I wonder if <isindex> is still implemented in all browsers |
| 11:22 | <mkwst> | annevk: I dropped it from Chrome. I think folks from Opera and Mozilla were sad about that. |
| 11:35 | <MikeSmith> | mkwst: did you ever find an acceptable (context-appropriate) synonym for the world "credential"? |
| 11:36 | <mkwst> | nope. |
| 11:36 | <mkwst> | I'm calling them credentials until someone tells me to stop. |
| 11:37 | <MikeSmith> | SGTM |
| 11:41 | <mkwst> | MikeSmith: The only thing I can think of would be to rename the API to something like `navigator.auth`, which would cover the three things I care about, and exclude the many things I don't. That said, "auth" seems to promise a bit more than I think I can deliver. *shrug* |
| 11:53 | <MikeSmith> | mkwst: yeah I'd say you already went above and beyond on trying to address the naming concern (and the imagined confusion it might cause for actual devs) |
| 11:53 | <mkwst> | MikeSmith: I'd say the same! But whatever. I don't want to stop on their namespace if there's a reasonable think I can call the thing I want to build that doesn't use the word they love so much and have defined so strangely. |
| 11:54 | <MikeSmith> | well |
| 11:54 | <MikeSmith> | they don't own any namespace on this |
| 11:54 | <MikeSmith> | despite what they might try to imply/assert |
| 11:54 | <mkwst> | No, of course not. But, politeness etc. |
| 11:54 | <MikeSmith> | sure |
| 11:55 | <mkwst> | They wrote their strange spec before I made mine public, so. *shrug* I'm friendly. :) |
| 11:55 | <MikeSmith> | we clearly need to version words |
| 11:56 | <MikeSmith> | "You mean 'credentials2', right? I'm talking about 'credentials1'." |
| 12:12 | <mkwst> | well, we have that. "I'm talking about https://w3c.github.io/webappsec/specs/credentialmanagement/#credentials, you're talking about https://web-payments.org/specs/source/identity-credentials/#dfn-credential."; |
| 12:22 | <MikeSmith> | hahah |
| 12:24 | <annevk> | You can instantly tell who's using ReSpec |
| 12:26 | <MikeSmith> | mkwst: just bind to those URIs some arbitrary prefixes that require looking back somewhere else in the conversation/world to resolve, and you have an world-class extensible solution to your problem |
| 12:26 | <annevk> | SimonSapin: how do you say "simply reverse engineering browsers." in French? |
| 12:26 | annevk | wants to reply to https://twitter.com/Titi_Alone/status/639024422049984512 |
| 12:27 | <annevk> | hsivonen: https://github.com/whatwg/html/pull/66 made the ISO-2022-JP thing a should, otherwise addressed your comments |
| 12:28 | <caitp> | does the URI spec really require you to parse IPv4 with each byte encoded as octal or hex? |
| 12:29 | <annevk> | caitp: URL does, URI doesn't |
| 12:29 | <MikeSmith> | hey it's caitp (long time no see) |
| 12:30 | <annevk> | (URI is obsolete though) |
| 12:30 | <caitp> | I use them interchangeably for some reason |
| 12:30 | <MikeSmith> | for those who like stuff related to range checks in Python: https://github.com/whatwg/wattsi/pull/1 |
| 12:32 | <annevk> | s/Python/Pascal/? |
| 12:32 | <annevk> | Assigned to Hixie |
| 12:33 | <MikeSmith> | thanks |
| 12:33 | <MikeSmith> | yeah, Freudian slip |
| 12:34 | <MikeSmith> | anyway I guess now that we have a "wattsi as a service", that PR is somewhate moot. And Hixie might reject it. And if he does I won't be unhappy. And I will at least have done the Right Thing by trying actually fix it. |
| 12:59 | <annevk> | johnme: thank you! |
| 12:59 | <annevk> | johnme: just noticed that's your first commit too, great |
| 13:06 | <MikeSmith> | there's an attr() function in CSS now? https://github.com/w3c/css-validator/issues/24 (I guess I vaguely recall) |
| 13:07 | <MikeSmith> | ah, since 2.1 (dinnet now) |
| 13:08 | <darobin> | yeah, but it hasn't been reliably implemented, at least it didn't use to be, haven't checked in a while |
| 13:08 | <MikeSmith> | hey darobin |
| 13:08 | <MikeSmith> | ok |
| 13:08 | <darobin> | hey man |
| 13:12 | <MikeSmith> | darobin: I've decided to switch over to focusing most of my time to debugging Free Pascal code from now on |
| 13:12 | <darobin> | MikeSmith: that sounds like a precious life skill |
| 13:13 | <darobin> | somehow I get the feeling that if I hadn't just bailed I might have found myself drawn into the same... |
| 13:13 | <darobin> | good instinct, there |
| 13:14 | <jgraham> | MikeSmith: Don't knock it, if you believe http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Object Pascal is like the 14th most popular programming language |
| 13:15 | MikeSmith | looks |
| 13:15 | jgraham | tries not to draw attention to the word "if" in that sentence |
| 13:16 | <MikeSmith> | I like Hixie's ranking-by-alphabet much better. |
| 13:16 | <MikeSmith> | that listing overcomplicates things with arbitrary criteria |
| 13:18 | <jgraham> | Hixie's ranking probably overstates how good VisualBasic is, however :p |
| 13:26 | <gsnedders> | MikeSmith: CSS 2.1 attr() is widely supported. CSS 3 attr() isn't. |
| 13:28 | <johnme> | annevk: thanks for reviewing :) |
| 13:31 | <MikeSmith> | jgraham: :) zsh shell scripting #1! |
| 13:31 | <MikeSmith> | gsnedders: ah OK |
| 13:58 | <JakeA> | annevk: trying to pick a day for the next sw f2f. Ted wasn't keen on using the plenary day, that leaves Monday or Tuesday. I imagine either of these will cause clashes. Any preference? |
| 14:06 | <annevk> | JakeA: either is fine with me |
| 14:17 | <SimonSapin> | annevk: a translation of "reverse engineering" exists, but no-one uses it. I replied to that tweet |
| 14:18 | <annevk> | ta |
| 14:51 | <wanderview> | annevk: mkwst: gecko supports request.formData() |
| 14:51 | <wanderview> | not sure which version it was implemented in, though |
| 15:49 | <darobin> | a CORS-related error is never detectable from either XHR or Fetch, right? |
| 15:59 | <annevk> | darobin: correct |
| 15:59 | <darobin> | yeah, the PouchDB people are on crack |
| 16:00 | <darobin> | annevk: it seems to be a common misconception that status:0 means CORS error; I guess that's because devs never see other network errors |
| 16:01 | <annevk> | darobin: heh, that just means "network error" |
| 16:01 | <annevk> | and there's more and more reasons you can get them, too |
| 16:01 | <darobin> | annevk: yeah, right — but since in regular development contexts you never get any except when you forget to switch CORS on, people assume this |
| 16:02 | <darobin> | one more reason against numeric error codes :) |
| 16:02 | <annevk> | Everything folks believe about CORS is likely wrong. Such a sad protocol. |
| 16:03 | <darobin> | lol |
| 16:03 | <annevk> | And yes, numeric codes are not great... |
| 16:04 | <annevk> | wasm is a pretty exciting "binary" format where all the numbers are variables coming from a map at the start of the file that maps feature strings to these variables |
| 16:04 | <annevk> | Rather than having standardized opcodes |
| 16:06 | <Ms2ger> | annevk, why is createDocument black and createHTMLDocument orange in https://dom.spec.whatwg.org/#dom-domimplementation-createdocument ? |
| 16:07 | <annevk> | Ms2ger: the Bikeshed conversion... |
| 16:07 | <annevk> | Ms2ger: it removed all the <code> inside <dfn> |
| 16:07 | <Ms2ger> | Fun |
| 16:07 | <annevk> | In a way |
| 16:11 | <ccardona-work> | Good morning/afternoon/evening whatwg crew o/ |
| 16:15 | <annevk> | ccardona-work: evening |
| 16:16 | <daleharvey> | darobin: cheers for the vote of confidence, we only use it to inform the user of a very regular problem they come up against |
| 16:17 | daleharvey | sees the issue on github |
| 16:18 | <annevk> | daleharvey: pointer? |
| 16:18 | <daleharvey> | https://github.com/pouchdb/pouchdb/pull/4190 |
| 16:19 | <annevk> | daleharvey: ta |
| 16:19 | <annevk> | daleharvey: I guess if that's the most common error for pouchdb saying that, while also saying it could be something else might be the best way forward |
| 16:20 | <daleharvey> | yeh the wording can be changed, it does say 'seems to indicate' but could be a little clearer |
| 16:21 | <annevk> | daleharvey: you could also not use it for same-origin requests, though redirects make that tricky |
| 16:22 | <darobin> | daleharvey: sorry if "on crack" came across as maybe a little brisk, it's just an expression :) |
| 16:22 | <darobin> | daleharvey: another improvement is that, in this case, the abort is actually triggered by Pouch |
| 16:22 | <darobin> | so you know it's a timeout |
| 16:23 | <ccardona-work> | annevk: o/ |
| 16:26 | <darobin> | daleharvey: I've pointed out the timeout source in the bug |
| 16:33 | <ato> | annevk: Existing WebDriver implementations have special instructions for how to handle showModalDialog(). HTML says it’s in the process of being removed, but I wonder what your thoughts are on whether our spec should say anything about them, considering it is directed at primarily new implementations. |
| 16:34 | <ato> | Does anyone know if Edge implements it? |
| 16:34 | <Ms2ger> | Allegedly not |
| 16:36 | <ato> | If it’s not in Gecko, Chrome, and Edge I guess I have my answer there, since Microsoft isn’t doing a WD implementation for IE11. |
| 16:38 | <Ms2ger> | ato, so what kind of instructions are those? |
| 16:39 | <ato> | Ms2ger: Ways of interacting and dismissing the dialogue, and some behaviour to automatically dismiss them if a top-level browsing context is discarded. |
| 16:40 | <Ms2ger> | Aha |
| 16:41 | <Domenic> | ato: it is not in Chrome or Edge or mobile Safari. Gecko is the only remaining major implementer. |
| 16:42 | <ato> | Domenic: And in Gecko it’s doesn’t work in Nightly anymore (even if the deprecation bug is still open). |
| 16:45 | <Domenic> | can someone test desktop safari for me actually? http://www.thesaabsite.com/js/safari-5.1-bugfix-test.html |
| 16:51 | <astearns> | Domenic: Mac desktop 8.0.8? |
| 16:51 | <Domenic> | astearns: sure |
| 16:51 | <astearns> | OK works in both. Cancel for prompt clears field, Cancel on showModalDialog sets to "<null>" |
| 16:51 | <astearns> | prompt comes up much quicker |
| 16:51 | <Domenic> | fascinating |
| 16:52 | <Domenic> | so they really did only kill it on mobile |
| 16:59 | <annevk> | "I sent a more detailed e-mail to the TAG where I think the discussion has per force moved to" going to continue to stay out of this |
| 16:59 | <smaug____> | IIRC we have so high usage numbers for showModalDialog that we can't really remove it real soon |
| 17:00 | <annevk> | smaug____: our numbers are different from Chrome? |
| 17:00 | <annevk> | smaug____: did all the existing Chrome users switch to Firefox? |
| 17:04 | <smaug____> | would be better to ask mrbkap |
| 17:05 | <smaug____> | but, IIRC, the idea was to not implement it for e10s, but the usage was high enough that the decision changed |
| 17:08 | <smaug____> | (also, showModalDialog hasn't been an issue for Gecko from implementation point of view, which is why there hasn't be rush on removing it) |
| 17:29 | <smaug____> | mounir: I assume blink is ok to change its presentation API implementation |
| 17:29 | <smaug____> | quite a bit perhaps |
| 17:29 | <smaug____> | perhaps it hasn't shipped yet |
| 17:32 | <smaug____> | so silly over-Promise-fying |
| 18:07 | <MikeSmith> | mkwst: it seems like http-equiv="Content-Security-Policy" needs to be added to the allowed values for http-equiv in the spec at https://html.spec.whatwg.org/multipage/semantics.html#pragma-directives |
| 18:08 | <mkwst> | MikeSmith: Didn't I add that? |
| 18:08 | <MikeSmith> | oh |
| 18:08 | MikeSmith | looks |
| 18:09 | <mkwst> | Ah. I have a local branch on my work computer where I've mostly added that. You're not crazy, I'm crazy. :) |
| 18:09 | <MikeSmith> | I don't find it in the spec, not |
| 18:09 | <MikeSmith> | heh |
| 18:09 | <MikeSmith> | yeah I would have been surprised if you weren't on top of it already :) |
| 18:09 | <mkwst> | Yes. We need to add that. Basically copy/pasting the text from https://w3c.github.io/webappsec/specs/content-security-policy/#delivery-html-meta-element. |
| 18:09 | <MikeSmith> | even if it is just locally |
| 18:09 | <MikeSmith> | yes |
| 18:10 | <MikeSmith> | people are using it |
| 18:10 | <MikeSmith> | see http://stackoverflow.com/questions/32359701/is-multiline-meta-content-value-alowed |
| 18:10 | <MikeSmith> | or see my answer there at http://stackoverflow.com/a/32359837/441757 |
| 18:16 | <mkwst> | Yes. It's the easiest way to deploy for some folks. github Pages, for instance. |
| 18:17 | <mkwst> | Would you mind filing a spec bug and assigning it to me so I remember to unmonkeypatch that bit tomorrow? |
| 18:21 | <MikeSmith> | hai |
| 18:27 | <MikeSmith> | hmm apparently it won't let me assign it to you |
| 18:27 | <MikeSmith> | we only have one team associated with this repo and that team doesn't have you as a member |
| 18:28 | MikeSmith | will figure something out |
| 18:28 | <mkwst> | *shrug* Whatever. I don't need superpowers. :) I see the bug, and I'll throw out a PR tomorrow. Thanks! |
| 18:32 | <MikeSmith> | cheers |
| 18:40 | <gsnedders> | hmm, I'm getting an internal server error from bugs.webkit.org o_O |
| 19:46 | <annevk> | yet more icons for https://github.com/whatwg/html/commits \o/ |
| 19:50 | <annevk> | MikeSmith: if you give someone read access, can you assign things to them? |
| 19:51 | <annevk> | MikeSmith: if that was feasible we could have a large read access team for html to make these kind of things easier; not sure I want to enlarge the group of folks that has push access at this point |
| 19:53 | <Domenic> | On GitHub? Hmm we can test this. |
| 19:53 | <Domenic> | I was thinking similar thoughts |
| 19:56 | <Domenic> | annevk: yes, it works |
| 19:57 | <Domenic> | annevk: a bit annoying you can't give it to anyone in the org |
| 19:57 | <Domenic> | annevk: I made https://github.com/orgs/whatwg/teams/html feel free to either add a bunch of people or merge it with https://github.com/orgs/whatwg/teams/contributors (which you would need to add read access to html on) or whatever |
| 20:01 | <annevk> | Domenic: I'm not sure why we have the latter team still |
| 20:01 | annevk | adds mkwst |
| 20:02 | <annevk> | (to html) |
| 20:02 | <mkwst> | Hrm? |
| 20:02 | <annevk> | mkwst: see GitHub invites, it's mostly so we can assign issues to you :-P |
| 20:03 | <mkwst> | SGTM. |
| 20:04 | <Domenic> | annevk: I kind of thought of it as basically for situations like this. we'd add everyone in the org and add read access to every spec\ |
| 20:04 | <mkwst> | I am now a member of WHATWG, but I can't self-assign https://github.com/whatwg/html/issues/88. |
| 20:04 | <Domenic> | annevk: but let's kill it and use html then. if we have another spec we want to do it for we can just rename the team |
| 20:05 | <Domenic> | mkwst: hmm yeah I think only people with push access can assign. Kind of lame. |
| 20:05 | <mkwst> | No worries. Someone will assign it to me, I'm sure. |
| 20:08 | <mkwst_zzz> | Night all. |
| 21:34 | <gsnedders> | Trying to sort out the divergences of the Blink fork of html5lib-tests… |
| 21:34 | <gsnedders> | Anyone want to tell me what "<div><a><b><div><div><div><div><div><div><div><div><div><div></a>" should result in, with any confidence? |
| 21:34 | <gsnedders> | AAA limit test! |
| 21:40 | <jgraham> | gsnedders: Whatever gecko does, or we change the spec :p |
| 21:42 | <gsnedders> | OK, we seem to have interop at least |
| 21:42 | <gsnedders> | the Blink version of the test is just wrong |
| 21:42 | <gsnedders> | v. everyone |
| 21:48 | <nox> | gsnedders: Is that in html5lib-tests? |
| 21:48 | <nox> | Oh you said that. I can't read. |
| 22:08 | <mounir> | smaug____: what's the problem with presentation api? |
| 22:08 | <smaug____> | just a bit over-engineered API |
| 22:08 | <smaug____> | too much Promise usage etc |
| 22:09 | <smaug____> | I'll file some bugs |
| 22:09 | <mounir> | smaug____: you might be too late to the game but feel free to file bugs |
| 22:09 | <smaug____> | not the first time I've seen overuse of Promises |
| 22:09 | <smaug____> | mounir: how so? |
| 22:09 | <smaug____> | it is not stable or anything |
| 22:09 | <mounir> | people have been working on this api for two years |
| 22:10 | <mounir> | not sure how open they are for cosmetic changes at that point |
| 22:10 | <smaug____> | People have worked on DOM APIs for decades,and still changing it ;) |
| 22:10 | <mounir> | but again, file bugs, I'm pretty sure anything reasonable will be considered |
| 22:10 | <smaug____> | mounir: the API has changed recently, and apparently the spec hasn't been reviewed |
| 22:10 | <mounir> | smaug____: I doubt people are making backward incompatible changes ;) |
| 22:10 | <mounir> | smaug____: define "reviewed" :) |
| 22:10 | <smaug____> | well, reviewed as "is it implementeable" |
| 22:11 | <smaug____> | implementable |
| 22:11 | <mounir> | smaug____: Mozilla is implementing that |
| 22:11 | <smaug____> | like there are some mistakes in webidl etc |
| 22:11 | <smaug____> | mounir: I know, I'm reviewing that work |
| 22:11 | <mounir> | smaug____: and unless something comes up, Chrome will ship that in the next Beta |
| 22:13 | <smaug____> | mounir: chrome has shipped plenty of unstable APIs, like shadow dom ;) |
| 22:13 | <mounir> | smaug____: I guess |
| 22:18 | smaug____ | wonders what chrome does when (new PresentationSessionConnectEvent("")).session is executed in the context where PresentationSessionConnectEvent is available |
| 22:19 | <smaug____> | that is a case broken in the spec, as an example |
| 22:19 | <smaug____> | looks like broken also in blink source cod |
| 22:19 | <smaug____> | e |
| 23:57 | <nox> | I think the adopting steps need to be run recursively in https://dom.spec.whatwg.org/#concept-node-adopt-ext. |