| 07:20 | <Ms2ger> | "I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG." |
| 07:21 | <heycam> | lucky for them such a thing exists |
| 12:12 | <hsivonen> | annevk: if a document's encoding is the replacement encoding, what should document.characterSet return when "replacement" isn't one of the encoding's labels? |
| 13:27 | <jgraham> | Ms2ger: 74s |
| 13:28 | <Ms2ger> | ? |
| 13:28 | <jgraham> | For the review |
| 13:29 | <Ms2ger> | Ah |
| 13:30 | <Ms2ger> | Next: under 60s :) |
| 13:30 | <jgraham> | Well now you have something to beat ;) |
| 13:30 | <Ms2ger> | Heh |
| 13:30 | Ms2ger | reruns his importing script |
| 14:00 | <zcorpan_> | if one doesn't want to get emails about comments https://github.com/hoppipolla-critic-bot makes, does it work to block that user? |
| 14:01 | <jgraham> | Perhaps? |
| 14:01 | <jgraham> | In the future it could potentially send more useful comments |
| 14:01 | <jgraham> | Like it could be an easy way to do merges directly from critic |
| 14:02 | <zcorpan_> | apparently art wants to pretend that critic doesn't exist |
| 14:02 | <zcorpan_> | or at least doesn't want to use it and doesn't want to get emails about it |
| 14:04 | <jgraham> | Well it's not clear if he is in principle opposed to all mail it sends or just that mail in particular |
| 14:04 | <jgraham> | I guess it's hard to tell at the moment since that's the only mail it sends |
| 14:04 | <jgraham> | Or, rather, that it causes GH to send |
| 14:05 | <annevk> | hsivonen: you return the name of the encoding, so "replacement" |
| 14:41 | <Ms2ger> | "See the whole threat on public-fx [1]." |
| 14:53 | <zcorpan_> | i wonder if public-fx is a list i should subscribe ot |
| 14:54 | <zcorpan_> | the only thread this month i care about is cross-posted to www-style, so i guess no |
| 15:07 | <Hixie_> | zcorpan_: i'm subscribed to it, but every few days i just do "select all recipient fx delete expunge", so... |
| 15:09 | <annevk> | zcorpan_: you should I think (I'm not) |
| 15:09 | <annevk> | zcorpan_: object model for CSS and SVG should be somewhat coordinated and similar |
| 15:10 | <zcorpan_> | k |
| 15:10 | <annevk> | At some point I thought the latter should be mostly obsoleted by the former... Not sure how true that is these days |
| 15:11 | zcorpan_ | *poof* |
| 15:21 | <hsivonen> | annevk: but if the label "replacement" appears in, say Content-Type, it's unknown and doesn't map to "replacement"? |
| 15:22 | <annevk> | hsivonen: correct |
| 15:22 | <hsivonen> | annevk: :-( I wonder if your APIs are prepared to deal with this kind of thing |
| 15:22 | <hsivonen> | I'll try to implement this and will report back |
| 15:22 | <annevk> | hsivonen: it's kind of an odd exception, would you prefer an explicit label? |
| 15:23 | <annevk> | hsivonen: I had the feeling we didn't really want to expose replacement more than required |
| 15:23 | <hsivonen> | possibly. I'll have to try how annoying the current state of the spec is |
| 15:23 | <annevk> | per spec architecture it makes perfect sense, but I can imagine it might be annoying elsewhere yeah |
| 15:45 | <Ms2ger> | A new css-ruby draft? Hear, hear |
| 15:48 | <annevk> | is it finally simplified or does it still try to cover all the potential use cases? |
| 16:25 | <dglazkov> | good morning, Whatwg! |
| 16:26 | <annevk> | This conference is pretty interesting. I didn't know that people put <iframe> inside <iframe> to circumvent people relying on window.onload before initializing a bunch of stuff (in the context of third party widgets). |
| 16:28 | <annevk> | Maybe there should be something like "I don't care about body's load event" |
| 16:28 | <annevk> | Or people should just generally not use it for larger setups... |
| 16:50 | <annevk> | Cookieless requests came up again too... |
| 17:12 | <annevk> | hsivonen: why does document.write() not throw for async scripts? |
| 17:12 | <annevk> | hsivonen: it's apparently annoying |
| 17:29 | <jgraham> | annevk left |
| 17:30 | <jgraham> | Seems like an odd thing to be annoyed about |
| 17:30 | <jgraham> | But didn't implementations lead here? Also I guess the script probably doesn't know that it's async at the moment |
| 18:08 | <zcorpan> | document.write() from createElement()ed scripts didn't throw before async="" |
| 18:15 | <Domenic_> | cookieless requests seem great, wouldn't they let you do cors-less cross-domain stuff? |
| 18:18 | <TabAtkins> | No, cookies aren't the only source of ambient authority. |
| 18:19 | <Domenic_> | :( what else is there |
| 18:20 | <TabAtkins> | Being on a given network, for example. |
| 18:20 | <Domenic_> | ugggh |
| 18:20 | <TabAtkins> | Yeah, the web's design sucks. :/ |
| 18:20 | <Domenic_> | it's just so silly to have to set up a proxy endpoint on one's server to do any cross-domain requests |
| 18:24 | <TabAtkins> | Agreed, but security is hard, and the web screwed it up super-bad early enough that we can only patch it now, not actually fix it. |
| 18:30 | <annevk> | Domenic_: opting out of HTTP authentication and something TLS user certificates would pave the way to that |
| 18:31 | <annevk> | Domenic_: I think we should have the ability to do those kinds of things same-origin, but requires more work figuring out the right hooks and getting implementations aligned with the new architecture |
| 18:32 | <Domenic_> | annevk: +1, building fetch from the ground-up by layering cookies etc. on top of a raw HTTP request seems sensible. But in terms of actual use cases my most prominent is cross-origin. |
| 18:33 | <annevk> | You mean tainted cross-origin? |
| 18:33 | <Domenic_> | no i mean just letting me see the damn data :P |
| 18:33 | <Domenic_> | in the same way i would see it if i set up a server-side proxy and went through that |
| 18:33 | <annevk> | You won't get cross-origin requests without CORS. |
| 18:34 | <annevk> | Except for tainted, but then you can't see the data (apart from height/width in case of images). |
| 18:34 | <Domenic_> | yeah, I guess that's what TabAtkins was explaining to me. Sad times. |
| 18:34 | <TabAtkins> | Proxying through your server wipes out all the ambient auth, which is why it's kosher. It's ugly, but it's not actually a hack - it has the desired security characterics. |
| 18:35 | <annevk> | Well, we should never have given the illusion from the start that intranets are protected. If security was thought through, it could've been the same... |
| 18:35 | <annevk> | It's IP-based intranet security that's biting us here... |
| 18:36 | <TabAtkins> | Yup. |
| 20:36 | <hallvors> | 'evening, annevk |
| 20:36 | <hallvors> | yt? |
| 20:36 | <annevk> | hallvors: good afternoon |
| 20:37 | <hallvors> | still somewhat confused about those serialize doc/encoding issues |
| 20:38 | <hallvors> | but seeing that the spec is sort of undecided too, it's not entirely my fault :) |
| 20:39 | <darobin> | heh |
| 20:40 | <hallvors> | annevk: any "current" thoughts on this? (If the rest of you would like context it's https://github.com/w3c/web-platform-tests/pull/343#issuecomment-24906702 onwards) |
| 20:41 | <annevk> | hallvors: Chrome doesn't support sending documents at all? |
| 20:41 | <annevk> | hallvors: do you get [object Document] or some such at least? |
| 20:41 | <hallvors> | nope |
| 20:41 | <hallvors> | it sends "Content-length: 0" , no content-type, no content |
| 20:42 | <annevk> | hallvors: if we can get away with serializing and then encoding to utf-8 bytes that'd be preferred |
| 20:42 | <darobin> | hallvors: is that the same for HTML and XML documents? |
| 20:42 | <annevk> | hallvors: seems like we can if Chrome doesn't even support stuff |
| 20:42 | <hallvors> | OK - that's what my rewritten test currently asserts ;-) |
| 20:42 | darobin | not entirely surprised, people get documents but rarely send them, and then likely as strings |
| 20:43 | <hallvors> | We could of course also make the test accept either behaviour as legal (with some real checks that the encoding label matches the on-the-wire bytes) |
| 20:43 | Ms2ger | does not approve of that |
| 20:44 | annevk | utters a Darth Vader noooo in silence |
| 20:44 | <hallvors> | (BTW Ms2ger - since you're around - consider the issues you raised about the exceptions tests fixed ;-)) |
| 20:45 | Ms2ger | tries to remember |
| 20:45 | <Ms2ger> | The one about the ByteString |
| 20:45 | <hallvors> | (And I'm glad you don't approve of that although it means more work for Gecko devs if you vote it down :-)) |
| 20:45 | <Ms2ger> | And what was the other? |
| 20:45 | <hallvors> | Some TypeError - |
| 20:45 | <hallvors> | tests are apparently slightly out of sync with spec :-/ |
| 20:45 | <Ms2ger> | Oh, the Blob |
| 20:45 | <hallvors> | oh yes, that one too |
| 20:45 | <Ms2ger> | No problem, thanks for filing the bugs |
| 20:45 | <hallvors> | will fix :) |
| 20:46 | <hallvors> | (sort of hoping all the errors are Anne's fault :-p) |
| 20:46 | <hallvors> | nah, sorry Anne ;-) |
| 20:47 | Ms2ger | has been dealing with twelve days of backlog :) |
| 20:48 | <Ms2ger> | hallvors, and just as a general comment, I find small, focused PRs easier to deal with than "fix all the bugs" ones |
| 20:49 | <Ms2ger> | (Not saying that I would be reviewing the smaller ones ;)) |
| 20:49 | <hallvors> | OK, I might consider that.. |
| 20:52 | <hallvors> | It's a bit hard to find nice ways to slice those assorted bugs into PRs.. |
| 21:05 | <annevk> | hallvors: hah, I'm sure they are |
| 21:05 | <annevk> | hallvors: I wrote those tests long ago, on the couch in richt's old apartment in Oslo |
| 21:05 | <annevk> | hallvors: no doubt things have changed |
| 21:06 | <darobin> | that plus remanent substances embedded in the couch |
| 21:06 | hallvors | will forever blame Rich's couch |
| 21:12 | <hallvors> | annevk; Ms2ger: http://xhr.spec.whatwg.org/#interface-formdata doesn't say that formdata.append() should throw any exceptions? |
| 21:12 | <annevk> | hallvors: IDL-level exceptions? |
| 21:12 | <Ms2ger> | Yeah |
| 21:12 | <Ms2ger> | You can't convert a string to a Blob |
| 21:13 | <hallvors> | OK |
| 21:13 | <Hixie_> | sweet kittens, the web makes no sense |
| 21:14 | <jgraham> | Woah, you only just realised? |
| 21:14 | <hallvors> | It merely reflects humanity. Humans don't make much sense either. |
| 21:14 | jgraham | is worried that Hixie_ has been asleep at the wheel |
| 21:14 | <jgraham> | :) |
| 21:14 | <jgraham> | hallvors: Now you sound like karl |
| 21:15 | <Hixie_> | i'm trying to figure out something about history.back() |
| 21:15 | <Ms2ger> | jgraham, if it'd been in the form of a haiku... |
| 21:15 | <Hixie_> | this API is on window.history |
| 21:15 | <Hixie_> | so you'd think it would affect window |
| 21:15 | <Hixie_> | but no! |
| 21:15 | <hallvors> | My new goal in life is to out-Karl Karl some day :) |
| 21:15 | <Hixie_> | it can affect some random other window, if it feels like it |
| 21:16 | <hallvors> | sub-frames that were navigated? |
| 21:16 | <Hixie_> | or parent frames |
| 21:16 | <Hixie_> | or sibling frames |
| 21:16 | <jgraham> | Well yeah, it changes the position in the global session history |
| 21:16 | <Hixie_> | or cousin frames |
| 21:16 | <Hixie_> | that makes precisely no sense. |
| 21:16 | <hallvors> | or third cousin frames. or grandparent frames. |
| 21:17 | <jgraham> | The global session history makes no sense? |
| 21:17 | <darobin> | the many joys of designing functionality in world where nested framesets are all the rage |
| 21:17 | <Hixie_> | i go back to: the web makes no sense. |
| 21:18 | <annevk> | Hixie_: many things you can access through the global are not limited to it |
| 21:18 | <jgraham> | Well the global session history is no fun to implement at least |
| 21:18 | <hallvors> | Hixie_.back() |
| 21:19 | <jgraham> | Oh, you did document.open/document.write during load. Pretend the load didn't happen" |
| 21:19 | <jgraham> | (iirc) |
| 21:22 | <Hixie_> | hmmmm |
| 21:23 | <Hixie_> | history.back() provides an interesting difficulty in situations where several browsing contexts with the same top-level browsing context have different event loops |
| 21:24 | <annevk> | good point |
| 21:24 | <annevk> | also UX vs API |
| 21:24 | <annevk> | as in UX innovation is made harder because we expose an API to control the functionality |
| 21:25 | <annevk> | although I suppose the back button doesn't have to be implemented in terms of the API (would make the API less useful) |
| 21:26 | <Hixie_> | what do you think are the odds that one of the htmlwg editors would fix this bug if i filed it on the htmlwg |
| 21:26 | <Ms2ger> | Ahahahahaha |
| 21:26 | <Hixie_> | it _should_ be a 5.0 blocker, since it's implemented functionality |
| 21:26 | <Ms2ger> | Ahem |
| 21:26 | <Hixie_> | right darobin? |
| 21:26 | <darobin> | :) |
| 21:26 | <darobin> | I dunno, do you just want it fixed or do you want it fixed right? |
| 21:26 | <Hixie_> | fixed right |
| 21:27 | <darobin> | that said, I don't know of any rule that would make it a 5.0 blocker |
| 21:27 | <darobin> | but then again there seems to have been process rules invented just for you |
| 21:27 | <Hixie_> | well you couldn't exit CR unless it was interoperably implemented, unless the w3c's ignoring its process again |
| 21:27 | <Hixie_> | or using one of its many "oh we don't really mean it" clauses |
| 21:27 | <darobin> | which is why I doubt it would make its way into there |
| 21:28 | <Ms2ger> | No, no |
| 21:28 | <Ms2ger> | Browsers work |
| 21:28 | <Ms2ger> | Hence, the spec is correct and interoperably implemented |
| 21:28 | <Ms2ger> | Thus we can go to rec |
| 21:28 | <darobin> | right! so it's fine :) we have, what's it called? "demonstrated interoperability" |
| 21:28 | <Hixie_> | oh right, i forgot, we proved the spec was right |
| 21:28 | darobin | has his process work done by Ms2ger, usually works out well |
| 21:29 | <Hixie_> | sigh |
| 21:29 | <annevk> | W3C shipping "good enough" makes sense given the patent policy |
| 21:30 | <darobin> | well yeah |
| 21:30 | <Hixie_> | yeah, we wouldn't want to have the patent protection cover what's actually implemented |
| 21:30 | <annevk> | It's kinda useless for all other things though and for "good enough" there's way too much politics |
| 21:31 | <darobin> | it's good to have patent protection cover what's reasonably well defined |
| 21:31 | <annevk> | Hixie_: it'd be better sure, but with limited time something has got to give |
| 21:31 | <Hixie_> | well if anyone has a patent on how history.back() works, the spec won't cover it |
| 21:31 | <annevk> | Hixie_: and with infinite time you don't get protection |
| 21:31 | <Hixie_> | annevk: if there was limited time, we could have gone to REC five years ago |
| 21:31 | <annevk> | Hixie_: right, but you'd get the other features covered |
| 21:31 | Hixie_ | long ago proposed going to REC every year |
| 21:31 | <annevk> | Hixie_: agreed |
| 21:32 | <Hixie_> | so clearly that's not it either |
| 21:32 | <Hixie_> | anyway |
| 21:32 | <darobin> | Hixie_: if someone has a patent that accurately describes how history.back() works, they deserve the money |
| 21:32 | <Hixie_> | anyone got an idea on this history.back() thing? |
| 21:32 | <annevk> | Hixie_: smaug____ does |
| 21:32 | <annevk> | and jgraham I suppose |
| 21:32 | <Hixie_> | given that presto and gecko both just have one event loop... |
| 21:32 | darobin | wants to go to Rec every year, not sure why people hesitate about it |
| 21:33 | <smaug____> | yes, didn't jgraham promise to write a spec about session history :) |
| 21:33 | <Ms2ger> | Hixie_, it's quite simple, people still want to make it seem like the process is followed |
| 21:33 | <Ms2ger> | Hixie_, that may be silly, but that's how it works |
| 21:33 | <Hixie_> | w3c sucks, news at 11. about this event loop problem... |
| 21:34 | <Hixie_> | do we need some sort of cross-event-loop synchronisation primitive? |
| 21:34 | <Hixie_> | that would suck the big one |
| 21:35 | <Ms2ger> | Or define a single event loop? :) |
| 21:35 | <Hixie_> | that wouldn't be compatible with per-origin process isolation |
| 21:37 | <annevk> | Hixie_: I recommend asking abarth |
| 21:39 | <annevk> | Hixie_: per http://www.chromium.org/developers/design-documents/oop-iframes they will track history globally |
| 21:40 | <annevk> | Hixie_: see "Navigation" |
| 21:43 | <Hixie_> | "We will also change the representation of a tab's session history to more closely match the HTML5 spec" |
| 21:43 | <Hixie_> | :-o |
| 21:43 | <Hixie_> | ok so basically they're planning on having a master event loop |
| 21:44 | <Hixie_> | just for navigation |
| 21:44 | <Hixie_> | that's interesting |
| 21:44 | <Hixie_> | makes sense |
| 21:45 | <Hixie_> | bbiab |
| 22:01 | <abarth> | Hixie_, annevk: happy to answer questions |
| 22:01 | <jamesr__> | any parser folks around? i'm fairly certain that the "spin-the-event-loop" step in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata isn't actually implemented |
| 22:01 | <annevk> | abarth: seems the whitepaper answered them :) |
| 22:01 | <annevk> | ta |
| 22:01 | <abarth> | great :) |
| 22:01 | <jamesr__> | but it seems a bit tricky to test |
| 22:02 | <jamesr__> | if i understand correctly, to test this i'd need to insert a </script> into the document with a pending stylesheet and with a current script nesting level of zero |
| 22:03 | <annevk> | <link href=test rel=stylesheet><script> ... </script> |
| 22:03 | <annevk> | jamesr__: it might be implemented in a different way, e.g. by only pausing once you hit .offsetWidth or some such |
| 22:04 | <annevk> | (unless I'm not following this particular requirement at all) |
| 22:04 | <jamesr__> | well that example wouldn't be observably different |
| 22:05 | <jamesr__> | if you did setTimeout(foo); doc.write("</scr"+"ipt>"); bar(); with a pending stylesheet load, the spec appears to be saying that foo() could execute before bar() |
| 22:06 | <jamesr__> | so long as the script was running at nesting level zero |
| 23:03 | <Hixie_> | http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html - the web is indeed a mess. |
| 23:03 | <Hixie_> | jamesr__: looking... |
| 23:04 | <Hixie_> | jamesr__: it has to be implemented, because if you don't spin the event loop there, the style sheet can never load, since the networking tasks that load the style sheet are also queued on the event loop :-) |
| 23:06 | <Hixie_> | jamesr__: it might be that certain task sources are blocked, though (the same way the tokeniser is blocked in that case) |
| 23:16 | <gsnedders> | Hixie_: /Something/ needs to replace CAs. Badly. |
| 23:16 | <jamesr__> | d'oh, finally made a test case with a server component to delay the end of DOMContentLoaded and it just crashes chrome |
| 23:17 | <jamesr__> | Hixie_: what do you mean "the sheet can never load"? won't it load after executing the script? |
| 23:17 | <Hixie_> | the script is blocked on the style sheet loading |
| 23:18 | <jamesr__> | executing the script, or parsing the </script> ? |
| 23:19 | <Hixie_> | you're talking about "An end tag whose tag name is "script"", "if there is a pending parsing-blocking script", script nesting level is zero, step 3, right? |
| 23:19 | <Hixie_> | there's a script that is waiting to run, but it's blocked on a style sheet being loaded. the parser blocks, waiting for the style sheet to load; once it's loaded, the parser continues, which executes the script. |
| 23:20 | <jamesr__> | right, with you so far |
| 23:20 | <Hixie_> | so what's the question? |
| 23:20 | <jamesr__> | but that algorithm could be running due to document.write(), correct? |
| 23:21 | <Hixie_> | not re-entrantly, or the script nesting level wouldn't be zero, but sure, document.write() could be involved somewhere, i guess |
| 23:21 | <Hixie_> | probably would have to be, actually |
| 23:21 | <Hixie_> | i don't know how else you get a pending parsing-blocking script |
| 23:21 | <jamesr__> | in my test case i'm executing document.write() from a img onload |
| 23:22 | <jamesr__> | sorry, onerror |
| 23:22 | <jamesr__> | (not that it matters) |
| 23:22 | <Hixie_> | you wouldn't be in the parser then |
| 23:22 | <Hixie_> | so none of this would apply |
| 23:22 | <jamesr__> | what do you mean "you wouldn't be in the parser"? |
| 23:23 | <Hixie_> | you wouldn't have a pending parsing-blocking script |
| 23:23 | <Hixie_> | (i will have to disappear for 30 minutes or so in about 3 minutes) |
| 23:24 | <jamesr__> | hmm, but i have a <link rel=stylesheet ...> pending load and i'm doc.writing() a <script> tag in |
| 23:24 | <Hixie_> | to test this iirc you need something like <script>document.write('<link ...><script src=...><\/script>');</script> |
| 23:24 | <jamesr__> | ah, but the parser-inserted bit won't be set? |
| 23:24 | <Hixie_> | gotta go |
| 23:24 | <Hixie_> | bbiab |
| 23:24 | <Hixie_> | sorry |
| 23:24 | <jamesr__> | np |
| 23:25 | <gsnedders> | Can the various event loops in theory run in parallel? |
| 23:26 | <jamesr__> | gsnedders: not sure what you mean. tasks have to be run serially |
| 23:26 | <gsnedders> | Well, there are three (four?) event loops in the HTML spec. |
| 23:28 | <gsnedders> | Oh, I'm mixing up event loops with their task queues. nvm. |
| 23:28 | <jamesr__> | there are many task queues but only one event loop AFAIK. you can't run tasks in parallel |
| 23:28 | <gsnedders> | Yeah, indeed. |
| 23:28 | <jamesr__> | although some are re-entrant or have asynchronous sections that you can run in parallel |