| 00:07 | <ambv> | gsnedders: about simpletree, ask me again tomorrow |
| 00:08 | <ambv> | I have to see what the various options are (and for instance what can the PyPy guys use) |
| 00:14 | <ambv> | but I suspect nobody will miss it if it's gone. xml.etree and xml.dom.minidom are widely known, it makes sense for people to use them. |
| 00:15 | <ambv> | James' comment on simpletree.py says it all |
| 00:15 | <ambv> | "Really crappy basic implementation of a DOM-core like thing" |
| 05:50 | <Hixie> | heycam: what'd i do to get incremented? :-) |
| 05:50 | <heycam> | Hixie, the Cmd+R thing |
| 05:50 | <heycam> | Hixie, it was a flippant comment, but I'm sure it will save me some number of seconds when I accidentally do it next :) |
| 05:51 | <Hixie> | oh heh |
| 05:51 | <Hixie> | i did that when you asked for it, before i said "your wish is my command" :-) |
| 05:51 | <heycam> | ah :) |
| 05:51 | <heycam> | only saw it in the irc notification in #html-wg this morning |
| 05:52 | <Hixie> | #html-wg talked about it? o_O |
| 05:52 | <heycam> | no, there's a bot that announces changes |
| 05:52 | <Hixie> | oh |
| 05:52 | <Hixie> | i must have it muted |
| 09:18 | <ambv> | gsnedders: remove simpletree, if you ask me. I can prepare the PR. motivation: dom and etree are more useful in terms of interop. also, James' comment on simpletree.py: "Really crappy basic implementation of a DOM-core like thing" |
| 09:19 | <ambv> | most importantly though: 1.0 is *the* version to remove it, if at all. |
| 09:20 | <jgraham> | I think gsnedders agrees with you :) |
| 09:21 | <ambv> | jgraham: why hello there! |
| 09:21 | <ambv> | thanks for html5lib, James! |
| 09:21 | <jgraham> | I think I have previously disagreed on the basis that it can be mildly useful to have something we fully control for testing (although perhaps that is less true now that the porject is mostly stable) |
| 09:21 | <jgraham> | and on the basis that the scope for 1.0 should be as small as possible |
| 09:22 | <jgraham> | ambv: Thanks for your contributions :) |
| 09:22 | <ambv> | when did you get rid of beautiful soup treebuilder? |
| 09:22 | <ambv> | I vaguely recall that it was supported at some point |
| 09:23 | <jgraham> | I don't remember. Myabe not that long ago, although that was never working very well and BS4 now supports html5lib as a parser backend, so that makes life easier for us |
| 09:26 | <ambv> | jgraham: true. I have to look up how that works. bs4 doesn't use the entirety of html5lib, right? BS4 is a treebuilder on its own. |
| 09:26 | <ambv> | but more to the point: I will prepare the PR that removes simpletree. |
| 09:26 | <jgraham> | OK |
| 09:28 | <ambv> | jgraham: how about using http://www.w3.org/html/logo/downloads/HTML5_Logo_512.png as the logo for the GitHub html5lib org? |
| 09:29 | <jgraham> | Well it isn't MIT licensed for a start |
| 09:29 | <ambv> | and it has 5 in it |
| 09:29 | <ambv> | but so does the library name |
| 09:31 | <jgraham> | darobin: Speaking of licensing, I note that http://www.berjon.com/blog/2013/04/w3c-open-license.html takes a very W3C appraoch to dates in URLs :p |
| 09:38 | <SimonSapin> | Does / should html5lib use the encoding labels in http://encoding.spec.whatwg.org/ ? |
| 09:38 | <SimonSapin> | (https://github.com/SimonSapin/python-webencodings might help ;)) |
| 09:38 | <jgraham> | It probably should, yes |
| 09:39 | <jgraham> | That is not 1.0 material for sure though :p |
| 09:39 | <SimonSapin> | sure |
| 09:39 | <SimonSapin> | I see a label mapping in constants.py, but I don’t know if it’s the same |
| 09:41 | <jgraham> | That's based on what used to be in the HTML spec. I doubt it's the same |
| 09:59 | <ambv> | jgraham: OK, here you go. a logo for the library that is MIT licensed. https://github.com/ambv/html5lib-logo |
| 10:00 | <ambv> | I made this ™ |
| 10:00 | <darobin> | jgraham: hahaha, actually the only place I've ever liked dates to be in URLs is for blogs |
| 10:00 | <darobin> | because I like to know the time context of a given post |
| 10:01 | <jgraham> | darobin: So explain why the URL is 2013/04 and the post is 2013/05/03 :) |
| 10:01 | <darobin> | what? |
| 10:01 | <darobin> | oh fuck |
| 10:01 | <darobin> | that's a bug in my publishing system :) |
| 10:02 | <jgraham> | *that* was the part that reminded me of W3C :) |
| 10:02 | <SimonSapin> | darobin: is in a weird timezone |
| 10:02 | <darobin> | jgraham: isn't CC-BY MIT compatible? |
| 10:02 | <darobin> | (re the logo) |
| 10:02 | <darobin> | jgraham: yeah, good point |
| 10:02 | <darobin> | and to say I positively *hate* datedspace and have been arguing against it for essentially ever |
| 10:02 | <darobin> | oh well |
| 10:02 | <jgraham> | darobin: I expect they are compatible |
| 10:03 | <jgraham> | But two licenses are more complex than one |
| 10:03 | <darobin> | sure |
| 10:03 | <darobin> | it's just that if that's your concern, I would ignore it :) |
| 10:04 | <jgraham> | My concern is that I can't be bothered to check in the CC license and the attribution to whoever needs to be attributed for that logo, just to get a generic logo that doesn't quite fit the project anyway |
| 10:05 | <jgraham> | (I'm sure almost everyone using that logo is breaking the license, but oh well) |
| 10:08 | <jgraham> | (not least because the sample code appears to be in violation) |
| 10:16 | <darobin> | I guess we should sue then :) |
| 10:18 | <jgraham> | Pretty sure you wouldn't win :) |
| 10:18 | <jgraham> | But it might be quite funny? |
| 10:18 | <jgraham> | Actually that "pretty sure" is based on a model of a legal system ruled by common sense |
| 10:19 | <jgraham> | So I retract that |
| 10:23 | <ambv> | jgraham: so what do you think about the WHATWG-inspired html5lib logo? |
| 10:25 | <jgraham> | I'm not sure. Apart from the fact that I think the WHATWG logo reveals why Hixie isn't in graphic design, I think that it suggests html5lib is a WHATWG thing, which isn't quite true |
| 11:09 | <darobin> | not that I have any say, but I actually like ambv's logo *except* for the colour |
| 11:09 | <darobin> | I always thought that the WHATWG had picked the ugliest shade of green possible :) |
| 11:09 | <Philip`> | jgraham: I thought the WHATWG logo was designed by Matt Raymond, per http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/007923.html |
| 11:10 | <ambv> | darobin: jgraham: to make a little twist on things, we can change the color to W3C HTML5's orange instead |
| 11:11 | <darobin> | ambv: I have a better idea, in order to illustrate the value of design by committee, how about using BOTH the green and the orange? ;) |
| 11:11 | ambv | cried a little inside |
| 11:16 | <jgraham> | Hmm, I wonder if all the variations on that logo that we have used since are copyright infringement :) |
| 11:20 | <jgraham> | darobin: You mean an animated gif that loops and jumps between the green and the orange at a selection of unequal intervals? |
| 11:20 | <darobin> | jgraham: how about an animated gradient? |
| 11:22 | <ambv> | I know. |
| 11:22 | <ambv> | It should BLINK. |
| 11:23 | <jgraham> | I think that we need SVG and the circle should either be, green, orange, or a feed of gsnedders' webcam. At random. |
| 11:32 | <darobin> | why blink when you can marquee? |
| 11:33 | <ambv> | https://dl.dropboxusercontent.com/u/4830253/hip5lib.png |
| 11:33 | <darobin> | sweet! |
| 11:35 | <Ms2ger> | Where did you get such a nice photo of darobin? |
| 11:36 | <jgraham> | darobin? It's a photo-fit of Ms2ger, surely? |
| 11:37 | <darobin> | I have no spectacles |
| 11:37 | <darobin> | besides, I think those glasses convey the hipsterness of a python project extremely well |
| 11:40 | <jgraham> | A ruby fanboi accusing *python* of being hipster? hahaha |
| 11:41 | <ambv> | jgraham: https://github.com/html5lib/html5lib-python/pull/45 |
| 11:42 | <jgraham> | ambv: OK, can't review now (have real work…) but I don't think DOM is a good default treebuilder |
| 11:42 | <jgraham> | Since the python DOM implementation is pretty hopeless |
| 11:42 | <ambv> | jgraham: OK, it's more simpletree-like than etree |
| 11:42 | <jgraham> | Yeah, I know, but still |
| 11:43 | <jgraham> | I don't want to be a bad citizen by encouraging unsuspecting innocents to use it |
| 11:43 | <ambv> | that leaves etree. |
| 11:43 | <jgraham> | Indeed |
| 11:44 | <ambv> | OK, will update and rebase (and break Critic again, yays ;-)) |
| 11:45 | <jgraham> | Why rebase? |
| 11:45 | <jgraham> | Or, to put it diffrently, please don't break critic :) |
| 11:45 | <ambv> | OK, will use --fixup. |
| 11:46 | <jgraham> | Yeah, that's much better style |
| 11:46 | <ambv> | jgraham: are you very tied to Critic? now that we're on GitHub, we might as well use that. |
| 11:46 | <Ms2ger> | ehehehe |
| 11:46 | <jgraham> | I am very very tied to critic having used the github review tools |
| 11:46 | Ms2ger | sits back with popcorn |
| 11:46 | <jgraham> | For a service that is generally good they are embarassingly poor |
| 11:47 | <jgraham> | Ahem |
| 11:47 | <jgraham> | Anyway, rebasing *does* work with critic |
| 11:47 | <jgraham> | And might even work with the critic/github integration, as long as you tell critic before you push that a rebase is going to occur |
| 11:48 | <jgraham> | But gratuitously rebasing pushed branches is bad style; you should squash right at the end before you want to merge with/rebase onto master |
| 11:49 | <jgraham> | Unless you need to incorporate some other changes that happened in master in the meantime |
| 11:50 | <jgraham> | (but if you need that tyou probably don't want to throw away the exisitng comments, so the github solution doesn't seem ideal) |
| 11:51 | <ambv> | I agree in general. For projects that use GitHub for the whole PR workflow the idea is to have the PR ready for automatic merging (by the big green button) at all times |
| 11:52 | <ambv> | For lines of code commented in the review it also integrates nicely since they are marked as "outdated diffs" then |
| 11:55 | <ambv> | jgraham: I will leave dom for Genshi |
| 11:56 | <gsnedders> | jgraham: What's the status for PyPI? |
| 11:56 | <ambv> | hello, gsnedders |
| 11:56 | <gsnedders> | ambv: (I'll be on train for most of today, FWIW) |
| 11:57 | <jgraham> | gsnedders: I need to actually do stuff but yes in theory I now can do stuff |
| 11:57 | <gsnedders> | jgraham: tl;dr: jgraham is lazy. |
| 11:58 | <ambv> | jgraham: FWIW if we remove simpletree then we might switch the default DOM implementation to a better one as well |
| 11:58 | <gsnedders> | Also: what's this without trains being totally fucked up on a bank holiday? |
| 11:58 | <ambv> | same backward incompatibility |
| 12:00 | <jgraham> | ambv: BTW the "outdated diff" thing on github is also totally broken since it assumes that any new change renders all previous comments irrelevant. Which is obviously a total lie. |
| 12:06 | <Ms2ger> | OH: "a very happy user of the MS Word Equation Editor" |
| 12:06 | <gsnedders> | Ms2ger: Are you sure you didn't just mishear? |
| 12:08 | <jgraham> | Perhaps it's just a test so you you know that the valium has kicked in as in: "How can you tell that the drugs work? Well I am a very happy user of the MS Word Equation Editor" |
| 12:10 | <Ms2ger> | https://groups.google.com/d/msg/mozilla.dev.platform/96dZw1jXTvM/JV5Ls2Dj73kJ |
| 12:10 | <Ms2ger> | (People might be interested in the rest of the thread as well) |
| 12:14 | <jgraham> | FWIW I once proposed that we made the parser accept a subset of (La)TeX and output a MathML DOM on the backend |
| 12:21 | <zewt> | never understood people squashing things before merging in git; much nicer to have the commits split out |
| 12:22 | <odinho> | Neh, better with nice history. Seeing all related changes on blame etc. |
| 12:22 | <odinho> | IMHO |
| 12:22 | <jgraham> | Yes, because there's nothing I want more in my history than all your "fixup! typo in arguments" commits |
| 12:22 | <zewt> | keeping them split apart is what gives you the nice history, instead of a bunch of work crushed into one mysterious commit |
| 12:22 | <zewt> | eh? i fixup those before they go anywhere |
| 12:23 | <odinho> | zewt: No-no. We don't squash to a SINGLE commit. |
| 12:23 | <odinho> | zewt: We have commits which make sense. |
| 12:23 | <odinho> | zewt: Then all fixups go into one of those master commits, if they make sense there. |
| 12:24 | <odinho> | zewt: If it is indeed a new "extra set" of work, worthy of its own commit, it gets that. |
| 12:25 | Ms2ger | prefers to think of stacks of patches |
| 12:25 | <jgraham> | The only things that should come in stacks are pancakes |
| 12:26 | <Ms2ger> | Queues, I guess |
| 12:26 | <Ms2ger> | The only things that should come in queues are Brits? |
| 12:27 | <jgraham> | Queues might be involved in procuring stacks of pancakes, for sure |
| 12:27 | <zewt> | a stack seems to imply they're all going to be reverted, heh |
| 12:27 | <tomasf> | pancake collections should be queues. you don't want to eat the coldest one last |
| 12:28 | <zewt> | pancakes don't really seem like stacks, since you don't pop them off and eat them one at a time |
| 12:28 | Ms2ger | imagines zewt with several pancakes in his mouth |
| 12:29 | <zewt> | :* |
| 12:29 | <jgraham> | A hetrogenous collection of pancakes should be arranged in a heap sorted according to flavour |
| 12:30 | <zewt> | whoever first called them a "stack of pancakes" sure had a poor understanding of data structures |
| 12:31 | <Ms2ger> | More like :∷ |
| 12:31 | <tomasf> | pancakes should be hung on a clothes line for random access |
| 12:32 | <Ms2ger> | Looks like jgraham found a new kind of nerd-snipe |
| 12:32 | <darobin> | fools |
| 12:33 | <darobin> | pancakes should be eaten fast enough that the data structure does not matter |
| 12:33 | <darobin> | it's a real time thing |
| 12:33 | <Ms2ger> | WebRTP |
| 12:33 | <darobin> | if you can't parallelise the baking and eating, you don't deserve access to a stove |
| 12:33 | <zcorpan> | should i put the old changelogs in html-differences in a <details>? |
| 12:34 | <darobin> | zcorpan: more importantly, have you considered changing the title? |
| 12:34 | <Ms2ger> | Does anybody implement details? |
| 12:34 | darobin | ducks for cover |
| 12:34 | <jgraham> | zcorpan: How is that relevant to pancakes? |
| 12:34 | <jgraham> | Also, no |
| 12:34 | <zcorpan> | Ms2ger: chrome does |
| 12:35 | <jgraham> | <details> is a bad idea until we have components that are widely implemented and can express it properly |
| 12:35 | <jgraham> | Isn't the chrome implementation kind of horrible? |
| 12:35 | <Ms2ger> | Meh, chrome :) |
| 12:35 | <zcorpan> | maybe |
| 12:41 | <darobin> | zcorpan: if you want something like details, but not details, don't be afraid of using some JS thing |
| 12:41 | <darobin> | (assuming you're not lazy about this) |
| 12:41 | <darobin> | so long as the default is to show the content, you can enhance |
| 12:42 | <zcorpan> | darobin: by 'the default' you mean without JS? |
| 12:42 | <darobin> | yeah |
| 12:42 | <darobin> | i.e. don't just display: none the hidden stuff |
| 12:42 | <zcorpan> | i think i'll go with the lazy card |
| 12:43 | <darobin> | I expected no less :) |
| 12:43 | <zewt> | itym more |
| 12:43 | <darobin> | no |
| 12:43 | <darobin> | I couldn't possibly have expected any less |
| 12:44 | <darobin> | also, a fine mind like zcorpan would naturally be driven to laziness |
| 12:44 | <gsnedders> | ambv, jgraham: BS3 support was removed around the time of fixing all the tests, as I wasn't prepared to hack stuff to sort of support a tree without namespaces. |
| 12:45 | <zcorpan> | maybe it's the tea |
| 12:48 | gsnedders | reads logs from earlier and while he's at it steals some of Ms2ger's popcorn |
| 12:50 | <Ms2ger> | Too late, I wasn't allowed popcorn in the computer lab |
| 13:45 | <ambv> | gsnedders: PR updated |
| 13:50 | <ambv> | …and another fixup for flake8 to add missing vertical whitespace |
| 14:17 | <ambv> | …and yet another fixup for PyPy to get rid of xml.etree DeprecationWarnings which are considered errors on Travis |
| 14:18 | <jgraham> | ambv: You know that critic sends notifications so that you don't have to ;) |
| 14:19 | <ambv> | jgraham: :-) he might know "what" but he won't know "why" |
| 14:19 | <ambv> | this is the dark side of "fixup!" |
| 14:22 | <jgraham> | True |
| 14:54 | <gsnedders> | ambv: git commit --fixup --edit allows you to edit the message (though you should really keep the first line the same!) |
| 14:54 | <ambv> | good to know. |
| 14:54 | <ambv> | thanks! |
| 15:45 | <hallvors> | annevk: tried to help you resolve a bug, see PR 4 for XHR spec |
| 15:53 | <hallvors> | annevk: two of the tests in http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm fails in Firefox just because there is a space before the word "charset". |
| 15:54 | <hallvors> | Isn't that a bit silly? Aren't both "text/html;charset=windows-1252" and "text/html; charset=windows-1252" valid MIME types? Should we make the tests a bit more accepting? |
| 15:58 | <hallvors> | (there's another test somewhere else that asserts charset must be upper case, i.e. charset=UTF-8 is expected even though charset=utf-8 was set. Does that make sense?) |
| 16:02 | <hallvors> | sorry, it's the other way around. Test sets lower case, expects lower case - Chrome upper cases UTF-8 and the test says failure. |
| 16:02 | <dglazkov> | good morning, Whatwg! |
| 16:41 | <annevk> | hallvors: just being conservative |
| 16:42 | <annevk> | hallvors: just in case servers mess up |
| 16:43 | <hallvors> | I'm somewhat tempted to rewrite to use assert regexp match to allow case insensitive and that single optional space.. |
| 16:43 | <annevk> | hmm |
| 16:43 | <annevk> | that's inconsistent with what's required though |
| 16:43 | <hallvors> | because I don't really think it's the XHR test suite's job to require such things for MIME types.. |
| 16:44 | <annevk> | well xhr makes that requirement |
| 16:44 | <annevk> | it requires a specific sequences of bytes, it doesn't require a particular mime type and leaves serialization up to the implementation |
| 16:56 | <hallvors> | annevk: if you say so. I'm trying to figure out where.. |
| 17:46 | <annevk> | hallvors: you cannot have same-origin and anonymous flag set |
| 17:52 | <annevk> | TabAtkins: yo, I'm your timezone |
| 17:52 | <TabAtkins> | annevk: Yay! |
| 17:52 | <annevk> | TabAtkins: fwiw, Future.resolve() also only takes a value; currently nothing in the API does something special with futures |
| 17:53 | <TabAtkins> | Future.all() takes futures. |
| 17:53 | <annevk> | TabAtkins: the only semantic is thenable assimilation or not |
| 17:53 | <hallvors> | annevk: Sorry, I don't get it. Where does it say I can't? |
| 17:53 | <TabAtkins> | Unless I just haven't read the algorithm lately, and it accepts plain values as auto-accepted promises? |
| 17:53 | <annevk> | hallvors: the place where it makes origin a unique identifier |
| 17:53 | <hallvors> | (did you mean it has no effect on same-origin?) |
| 17:54 | <hallvors> | open() - Set source origin to a globally unique identifier if the anonymous flag is set, and the origin of document otherwise. ??? |
| 17:54 | <annevk> | TabAtkins: per the algorithm, {then:function() {}} and new Future() are identical |
| 17:54 | <annevk> | hallvors: yes |
| 17:54 | <TabAtkins> | annevk: Yes, yes, that's fine (for the purpose of the relevant conversation). When I say "Future", read "thenable" for now (unless I get people to agree on changing that). |
| 17:55 | <annevk> | TabAtkins: oh man that's so confusing |
| 17:55 | <TabAtkins> | Haha. |
| 17:55 | <annevk> | TabAtkins: I think in part that's what's ruining this conversation |
| 17:55 | <TabAtkins> | There's "plain values", and there's promise-likes. |
| 17:55 | <annevk> | Because I'm pretty sure Mark has a different set of assumptions |
| 17:55 | <TabAtkins> | Mark is using his own weird set of terminology that's different from everyone else's. :/ |
| 17:56 | <hallvors> | hm.. nothing in that section about same vs cross origin. I think you mean under send(). Step 10. If the source origin and request URL are same origin etc |
| 17:57 | <hallvors> | here same-origin makes no reference to anonymous flag indeed |
| 18:01 | <hallvors> | Yup - have to remind myself that anonymous flag is basically just a way to turn off Referer: for cross-origin request.. |
| 18:02 | <annevk> | TabAtkins: so yeah, I guess we should write an email that is perfectly clear on terminology and then ask what invariants everyone wants |
| 18:03 | <annevk> | TabAtkins: because now I've the feeling everyone is saying something else and still agreeing with each other because they all think people mean different things |
| 18:03 | <TabAtkins> | No, there's definitely not agreement going on here. |
| 18:03 | <annevk> | hallvors: if the origin is a unique identifier, it can never be same-origin with the URL |
| 18:05 | <annevk> | TabAtkins: I think what might be worth trying is instead of using abstract terms is to ask people what they want if you pass new Future vs something that matches {then:function(){}} vs any other kind of value |
| 18:06 | <TabAtkins> | annevk: At the moment we're talking about straight-up Futures in the thread, though. |
| 18:06 | <annevk> | straight-up future? |
| 18:07 | <TabAtkins> | As in, Futures in and of themselves, not thenables (though much of it applies to thenables as well). |
| 18:07 | <TabAtkins> | In other words, we're not talking past each other about Futures vs thenables, at least at the moment. |
| 18:14 | <hallvors> | (I don't understand why anonymous is a constructor argument and withCredentials is a property.. seems a bit inconsistent. But that's a sin of the past..) |
| 18:16 | <hallvors> | I also like Jonas Sicking's suggestion to send Authorization immediately. Implementing that shouldn't really be harder than implementing sending a setRequestHeader('Authorization', ) |
| 18:16 | <hallvors> | - or? |
| 18:17 | <hallvors> | but I realise a lot of spec authoring is probably spent waiting for feedback :) |
| 18:20 | <hallvors> | I don't care much about the charset case issue. Allowing the optional space is IMO reasonable.. IMO it's more readable with a space.. but it's of course nitpick and hardly worth discussing. |
| 19:49 | <annevk5> | hallvors: we could do Authorization directly, if that's also done for user@pass in URLs I suppose. Or we could even make that differ... Someone just needs to outline all the different configurations and define it... |
| 19:49 | <annevk5> | hallvors: pretty much all of that should be in Fetch |
| 19:49 | <hallvors> | just a moment.. |
| 19:50 | <hallvors> | Opera (presto) sends it immediately when you type user:pass@host |
| 19:52 | <hallvors> | Firefox doesn't though |
| 19:52 | <lecuyer> | not to boil the pot, but is DRM still happening in html5? |
| 19:53 | <hallvors> | companies with a lot of clout are still pushing DRM, yes |
| 19:54 | <lecuyer> | in the "have been pushing"-"have successfuly pushed", where are we? |
| 19:55 | <hallvors> | Neither does Chrome. But it's a bit hard to tell if it's just anti-phishing strip-away-user-pass or a deliberate feature. I'll go fake some 401s.. |
| 19:59 | <hallvors> | Yes, it's a feature. They both require a 401 with a correct WWW-Authenticate challenge |
| 20:10 | <annevk> | Yeah, it's called HTTP authentication ;-) |
| 20:15 | <annevk> | hallvors: fyi, CORS is part of Fetch |
| 20:15 | <annevk> | hallvors: so in fact Fetch defines the whole thing, and XHR is just an API layer |
| 20:16 | <hallvors> | I basically don't care where it is defined as long as I can write sensible test cases and refer to some spec :-) |
| 20:16 | <hallvors> | The (largely theoretical) problem with sending Authorization immediately is that the server might request something else than Basic.. |
| 20:17 | <hallvors> | so we throw a spanner into the auth negotiation feature of HTTP if we did that |
| 20:17 | <hallvors> | (would throw) |
| 22:46 | <annevk> | ah yeah |
| 22:46 | <annevk> | that's why you need to get to the server |
| 22:46 | <annevk> | to get some details |
| 22:47 | <annevk> | oh |
| 22:47 | <annevk> | IE11 has __defineGetter__ |
| 23:01 | <annevk> | arv: there's various different open issues with respect to Document objects |
| 23:01 | <annevk> | arv: one is that HTML attempts to merge most of them into one |
| 23:02 | <annevk> | arv: which is good as getting different document objects based on MIME type was just confusing |
| 23:02 | <annevk> | arv: but whether it's compatible has yet to be fully tested |
