| 06:54 | <cortexA9> | hi |
| 07:57 | <zcorpan> | jgraham: does trickle(d1) send the headers immediately? |
| 08:16 | <Ms2ger`> | So it was true that FB was going to do Presto! |
| 08:16 | <Ms2ger`> | https://news.ycombinator.com/item?id=6684318 |
| 08:58 | <hsivonen> | oh, cool. utf-16le is now the name of the encoding and utf-16 is a label |
| 08:58 | <hsivonen> | this has changed recently, right? |
| 08:58 | <hsivonen> | anyway, I'm less annoyed now |
| 09:32 | <annevk-cloud> | Yeah was changed |
| 11:00 | <annevk> | So GPHemsley, should http://wiki.whatwg.org/wiki/New_work become a subpage too then? |
| 11:02 | <annevk> | GPHemsley: your spelling of acknowledgments disagrees with all my specs |
| 11:04 | <MikeSmith> | fwiw about setting up a way to get RF agreements for whatwg specs, I notice that the Dash Industry Forum is using a relatively lightweight means to get RF agreemenents for code contributions to the dash.js library. see https://github.com/Dash-Industry-Forum/dash.js/wiki/How-to-Contribute#process-for-contributing-code and, e.g., https://groups.google.com/forum/#!topic/dashjs/W4Tmm8sBGX0 |
| 11:05 | <MikeSmith> | it's for code, not specs, but it seems like the same thing could be used for spec contributions |
| 11:06 | <MikeSmith> | in fact, they actually just call it a "Feedback Agreement" |
| 11:06 | <MikeSmith> | http://dashif.org/documents/DASH-IF-Feedback-Agreement-5-9-2013.pdf |
| 11:06 | <MikeSmith> | "By signing below, you (on behalf of yourself if you are an individual and your company if you are providing Feedback on behalf of the company) grant the companies under all applicable intellectual property rights owned or controlled by you or your company a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, publish, license, modify, sublicense or otherwise distribute and exploit Feedback yo |
| 11:46 | <MikeSmith> | I'm trying to remember if there's data somewhere on how many documents on the Web are actually being served with an XML MIME type |
| 11:47 | <MikeSmith> | I mean documents with an XHTML doctype served with an XML MIME type instead of as text/html |
| 12:15 | MikeSmith | finds http://dev.opera.com/articles/view/mama-http-headers/#conttype |
| 12:16 | <MikeSmith> | 'Of the 3,509,180 URLs that MAMA analyzed, the vast majority (~99.9%) used a "text/html" MIME type' |
| 13:21 | <annevk> | MikeSmith: I hope you're just doing that because you're curious and not because someone is saying something irrational |
| 13:22 | <MikeSmith> | umm, I wish I could claim it was because someone isn't saying something irrational, so let's just go with "curious" |
| 13:28 | <annevk> | You know it's bad when you have to revisit a decade old fact-settled debate. |
| 13:31 | <hsivonen> | annevk: speaking of those: http://lists.suckless.org/dev/1310/17874.html |
| 13:33 | <annevk> | hsivonen: gopher man, how do you find this stuff? |
| 13:33 | <hsivonen> | annevk: hendry tweeted it at me |
| 13:33 | <annevk> | haha |
| 13:35 | <hsivonen> | I wonder if I should add telemetry for those font-only legacy Mac encodings |
| 13:36 | <annevk> | To see if the font code path is being hit? |
| 13:36 | <hsivonen> | annevk: right |
| 13:36 | <hsivonen> | maybe I should add telemetry for legacy stuff that Thunderbird might use, too |
| 13:37 | <annevk> | Is there any Mac OS out there that still needs that? |
| 13:37 | <annevk> | That Gecko supports? |
| 13:37 | <hsivonen> | annevk: I have no idea what fonts people have installed |
| 13:37 | <annevk> | Ooh, it's not an OS thing, it's a fonts thing? |
| 13:37 | <annevk> | Ew... |
| 13:38 | <hsivonen> | annevk: it's for making sense of data in legacy font files |
| 13:39 | <annevk> | I guess that does warrant investigation of sorts. Alternatively investigation of the Chrome code base which almost certainly does not do this. (They don't have those encoders/decoders at the Chromium level.) |
| 14:24 | <GPHemsley> | annevk: Yeah, there are a few more pages that should probably become subpages. |
| 14:43 | <GPHemsley> | Any chance we could start encouraging subject prefixes on the mailing list, like CSS and others do? (I know I do it with mimesniff.) |
| 14:45 | <zewt> | how about "Subject: " |
| 14:46 | <annevk> | GPHemsley: no |
| 14:46 | <GPHemsley> | why? |
| 14:46 | <annevk> | A lot of topics encompass lots of different specifications. We should not add bureaucracy that isn't needed. |
| 14:47 | <GPHemsley> | You have a low bar for what is considered "bureaucracy" |
| 14:47 | <annevk> | Yes |
| 14:48 | <annevk> | Everything that's a "rule" basically. |
| 14:48 | <annevk> | Don't need people that want to contribute to have to go through more rules than strictly needed. |
| 14:49 | <annevk> | It's already too hard for a bunch of them. |
| 14:49 | <GPHemsley> | On the flipside, it's hard for me to figure out what mail to read ;) |
| 14:50 | <Ms2ger> | All of it ;) |
| 14:50 | <GPHemsley> | Ms2ger: Do you really what my unqualified opinion on everything? ;) |
| 14:50 | <GPHemsley> | s/what/want/ |
| 14:51 | <Ms2ger> | I want you to read it, not necessarily to reply ;) |
| 14:51 | <darobin_> | GPHemsley: I think the hidden message there is that annevk doesn't want to contribute :) |
| 14:51 | <jgraham> | Not sure that reading every mail means responding to everything |
| 14:51 | <GPHemsley> | jgraham: 'Twas hyperbole ;) |
| 14:51 | jgraham | doesn't read every mail, but also doesn't want more rules for the sake of it |
| 14:52 | <darobin> | I find that if people use meaningful subjects you don't need a prefix |
| 14:53 | <annevk> | GPHemsley: I recommend reading the subjects that interest you |
| 14:53 | <annevk> | darobin: indeed |
| 14:53 | <darobin> | whereas people tend to get prefixes wrong, especially if there are more than two different ones |
| 14:53 | <annevk> | I'd be okay with a "use meaningful subjects" guideline, just like we have a "inline quote" guideline |
| 14:53 | <darobin> | that just falls under proper netiquette really |
| 14:53 | <annevk> | Yeah |
| 14:54 | <darobin> | maybe just training the spam filter to drop emails with poor netiquette would achieve excellent signal to noise |
| 15:11 | <SimonSapin> | This is nice Frenglish: "Initialized empty Dépôt git dans /home/simon/projects/specs/html/.git/" |
| 15:12 | <Ms2ger> | Why would you use a French OS |
| 15:13 | <SimonSapin> | old habits |
| 17:07 | <zcorpan> | anyone know about in-browser ITS tools? |
| 17:08 | <miketaylr> | ITS? |
| 17:11 | zcorpan | -> beijing -> shenzhen |
| 17:13 | <Hixie_> | wtf, a bunch of characters in the multipage acks got corrupted |
| 17:14 | <Hixie_> | oh i bet the problem is that some parser doesn't supported named references |
| 17:14 | <Hixie_> | annnnnnneeeeeeeeeeeeee |
| 17:28 | <marcosc> | heh, I was also going to curse Anne for something different :) |
| 17:33 | <jorendorff> | Domenic_: are microtasks going to be spec'd in ES6, and is there already draft text for it? |
| 17:36 | <Hixie_> | oh, if ES6 is gonna spec them that would make my life easier |
| 17:36 | Hixie_ | is currently deep in the middle of trying to figure out how to spec them in HTML |
| 17:41 | <jsbell> | jorendorff/Hixie: relevant (short) thread is https://mail.mozilla.org/pipermail/es-discuss/2013-October/033940.html |
| 17:42 | <jorendorff> | "easier"; "short" |
| 17:42 | <jorendorff> | OK, my real question was: how deterministic is the ordering of microtasks? |
| 17:43 | <Hixie_> | well i presume they're just going to provide hooks for HTML to use |
| 17:43 | <Hixie_> | it's not like they can actually embed the event loop directly into ES6, given how much HTML-specific crap is around the event loop |
| 17:44 | <jorendorff> | mmhmm |
| 17:44 | <Hixie_> | (e.g. when the event loop starts, etc) |
| 17:44 | <Hixie_> | (how it's used for non-script-related stuff) |
| 17:55 | <Hixie_> | today's monster is http://www.hixie.ch/tests/adhoc/html/script/callbacks/001.html |
| 18:00 | <Hixie_> | anyone got IE11 around? |
| 18:03 | <dglazkov> | good morning, Whatwg! |
| 18:36 | <annevk-cloud> | I can maybe fix bugs from China, otherwise in 10 days. |
| 18:37 | <annevk-cloud> | On the tube at the moment with no place to sit. Shit's clogged. |
| 18:39 | <annevk-cloud> | ES6 will just have a hook btw |
| 18:40 | <Hixie_> | if you're in an iframe and you call parent.setTimeout(parent.open, 0, 'a') -- should the 'a' be resolved relative to your own base URL, or should it be resolved relative to the parent's base URL? |
| 18:41 | <Hixie_> | everyone (except IE, which won't accept that construct at all) agrees it should be the parent's base URL, but nobody agrees as to why |
| 18:41 | <Hixie_> | in chrome it's because the setTimeout is from the parent |
| 18:42 | <Hixie_> | in firefox it's because the argument isn't a script but the argument comes from the parent |
| 18:42 | <Hixie_> | and in safari it's because the argument isn't a script but the setTimeout comes from the parent |
| 18:43 | <Hixie_> | firefox's answer is inconvenient since it would mean figuring out what global to use when you pass e.g. MessagePort.send to setTimeout |
| 18:43 | <Hixie_> | chrome's answer is lame because it means if you do parent.setTimeout(myownfunc, ...), myownfunc is going to resolve relative to the parent instead of relative to itself |
| 18:44 | <Hixie_> | seems crazy that you could change how a function works based on who's setTimeout you use |
| 18:44 | <Hixie_> | then again, it's already true that if you call a function in the parent frame directly, you change how it behaves relative to it being called by script in that frame... |
| 18:45 | <Ms2ger> | How about window.setTimeout.call(parent,...? :) |
| 18:45 | <Hixie_> | not sure i want to know |
| 18:46 | <Hixie_> | i assume that's the same as parent.setTimeout, at the webidl level |
| 18:46 | <Hixie_> | am i wrong? |
| 18:46 | <Ms2ger> | I'd hope so |
| 18:47 | <Hixie_> | let's assume so for the sake of this discussion |
| 18:49 | <Hixie_> | wait, safari's behaviour still requires answering the question above. damnit. |
| 19:42 | <Domenic_> | Hixie_: jorendorff: annevk-cloud: yeah my impression is there will be some abstract operation "queue a microtask" which ES uses, and doesn't actually specify how it works, besides maybe some invariants like clean-stack or ordering or something. |
| 20:00 | <jorendorff> | clean-stack, definitely; ordering is what i'm after... hmm. |
| 20:00 | <jorendorff> | i'll assume it's mostly deterministics |
| 20:16 | <annevk-cloud> | It will be deterministic jorendorff |
| 20:17 | <jorendorff> | ok! |
| 20:17 | <jorendorff> | Domenic_: i was able to remove all direct interaction with microtasks from the module loader stuff by using promises instead |
| 20:18 | <jorendorff> | Domenic_: little worried i'm not doing it right -- that spec is impenetrable, to me -- but i guess the bugs will shake out one stuff runs |
| 20:18 | <jorendorff> | *once |
| 22:08 | <Hixie_> | heycam! |
| 22:08 | <Hixie_> | so i've been studying browsers |
| 22:08 | <Hixie_> | http://www.hixie.ch/tests/adhoc/html/script/callbacks/001.html has my results and conclusions (see bottom) |
| 22:09 | <heycam> | oh my |
| 22:09 | <Hixie_> | yeah. |
| 22:10 | <Hixie_> | so the only real question that no browsers agrees with is how to determine the entry script (actually, the "settings object", i'll explain what i mean in the bug later) for cases where you call a method with a native method as the callback |
| 22:10 | <Hixie_> | as in setTimeout(open, ...) |
| 22:11 | <Hixie_> | there are several options: |
| 22:11 | <Hixie_> | 1. we don't support that (IE9) |
| 22:11 | <Hixie_> | 2. we use the data from the global of the method you called (setTimeout in this case) (Chrome, Safari) |
| 22:11 | <Hixie_> | 3. we use the data from the global of the method you passed as a callback (open in this case) (Firefox) |
| 22:12 | <Hixie_> | 4. we do our own new thing in the interests of sanity |
| 22:12 | <heycam> | to me, 3 sounds like it is more sensible |
| 22:12 | <Hixie_> | (btw Chrome and Safari are incompatible for the more common case of passing a script-defined function, so don't put too much in the fact that they agree on this question) |
| 22:12 | <heycam> | i.e. you look at the thing you will be invoking later |
| 22:12 | <Hixie_> | #2 and #3 have a problem: do we have a way to determine what "global" any random method is related to? |
| 22:13 | <heycam> | yes |
| 22:13 | <Hixie_> | oh excellent |
| 22:13 | <heycam> | Web IDL says every "initial object" is associated with a particular "global environment" |
| 22:13 | <Hixie_> | initial object is like the method? |
| 22:13 | <Hixie_> | what's a "global environment"? |
| 22:13 | <heycam> | yeah, it's basically all of the objects that exist before you run any scripts |
| 22:13 | <heycam> | (apart from the ES-defined ones) |
| 22:13 | <heycam> | "global environment" is something a bit fuzzy |
| 22:13 | <Hixie_> | so what if someone passes an ES-defined one? |
| 22:14 | <Hixie_> | like, toString |
| 22:14 | <heycam> | I guess my definition won't help there… maybe there is one in the ES spec? |
| 22:14 | <heycam> | not sure if the spec has begun to talk about realms yet or not |
| 22:14 | <Hixie_> | last i checked, the ES spec didn't acknowledge multiple globals |
| 22:14 | <Hixie_> | but i may not have checked for a while |
| 22:15 | <heycam> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-code-realms |
| 22:15 | <heycam> | ok so you can go from the toString object to the realm |
| 22:15 | <Hixie_> | what does the realm give you? |
| 22:15 | <heycam> | that table of things |
| 22:15 | <heycam> | including the global object |
| 22:15 | <Hixie_> | a global, we can use that |
| 22:16 | <Hixie_> | well if you can get from any random method (script-defined, ES-defined, or WebIDL-defined) to a global, i can do the rest |
| 22:17 | <heycam> | I can |
| 22:17 | <Hixie_> | ok, cool |
| 22:17 | <heycam> | whew! finally we can use style="" |
| 22:18 | <TabAtkins> | heycam: Hm? |
| 22:19 | <Hixie_> | hmmm... i need to move script origins to the settings object also |
| 22:19 | <heycam> | TabAtkins, sorry, just being facetious about http://www.w3.org/TR/2013/REC-css-style-attr-20131107/ becoming a Rec |
| 22:19 | <TabAtkins> | Ah, indeed. |
| 22:29 | <Ms2ger> | Time to deprecate style="" |
| 22:39 | <Hixie_> | i tried |
| 22:39 | <Hixie_> | people presented... compelling arguments |
| 22:39 | <Jasper> | i'm sure they did |
| 22:54 | <Hixie_> | TabAtkins: dunno if you're the right one to ask, but, are you on board with javascript: being killed in CSS url()s? |
| 22:54 | <TabAtkins> | I'm surprised those even work. Do they? |
| 22:54 | <TabAtkins> | Kill them. |
| 22:54 | <Hixie_> | probably not |
| 22:54 | <Hixie_> | ok |
| 22:55 | <Hixie_> | the plan is to move javascript: to just be a quirk of the navigate algorithm |
| 22:55 | <Hixie_> | i'm about to make the first move towards that, by removing the concept of scripts having origins, the bulk of which is concerned with defining the origin of javascript: scripts |
| 22:56 | <Hixie_> | christ, 1993 matches for "script" in the spec |
| 22:56 | <Hixie_> | this could take a while |
| 23:10 | <jorendorff> | Domenic_: interesting situation... the Loader's use of Promises is supposed to be kind of an implementation detail, unobservable |
| 23:10 | <jorendorff> | Domenic_: but at various points user scripts can screw us over by modifying the builtins |
| 23:11 | <jorendorff> | Domenic_: for example, CastToPromise calls GetDeferred which calls C.[[Construct]] which calls C[@@create], which is configurable |
| 23:11 | <jorendorff> | big ufn |
| 23:20 | <TabAtkins> | jorendorff: We're dealing with that too. The solution seems to be to have some way to provide clean built-ins to browser JS. |
| 23:21 | <Hixie_> | that's basically what we do for all the other things that are defined in terms of author-visible features |
| 23:21 | <jorendorff> | TabAtkins: oh, dherman has designed an API for this: new Realm |
| 23:21 | <jorendorff> | but all the methods are probably configurable |
| 23:21 | <Hixie_> | (though i've tended to just define things in terms of algorithms and then invoke the algorithms rather than the native features) |
| 23:22 | <Hixie_> | s/native/author-accessible/ |
| 23:23 | <jorendorff> | that's what I'm used to (algorithms), but Promises are high-level enough that it starts to break down |