| 00:01 | <astearns> | could be, or could be the <body> |
| 00:02 | <yroc> | Yeah, that seemed to be Hixie's point. But why not <article>, (it's a complete and syndicable composition)? |
| 00:02 | <yroc> | This has implications WRT Hixie's claim that nested articles would only be comments. |
| 00:03 | <astearns> | that claim makes no sense to me |
| 00:04 | <yroc> | OK, well, I seem to have agreement with you and TabAtkins. I guess I'll bring it up to Hixie next time I can catch him. |
| 00:10 | <Hixie> | bholley: pretty sure it was opera's model. by "non-web" i mean "not required to render web pages like other browsers" |
| 00:12 | <Hixie> | yroc: it's more a |
| 00:12 | <Hixie> | yroc: matter of "what is a comment?" |
| 00:13 | <Hixie> | yroc: if you have a book of short stories, and the stories are about the topic of the main book, then aren't the stories comments? |
| 00:13 | <Hixie> | comments on the topic of the book? |
| 00:14 | <Hixie> | anyway, gotta go again, sorry i keep only being here briefly |
| 00:14 | <zewt> | seems quite strange to me that several idb "complaints" seem to boil down to "follows platforms conventions" |
| 00:14 | <zewt> | not ordinarily considered a flaw |
| 00:14 | <bholley> | Hixie: well, it was required to ship a secure product that users could safely use in the face of the already-entrenched addon model, and one that was performant enough given the lack of a generational GC. It doesn't seem fundamentally different from WebKit's lack of a cycle collector making it impossible for them to implement certain things without leaking. What's web and not web really just depends on what ends up in the spec |
| 00:17 | <bholley> | Hixie: this is all to say that the html5 effort is one of interoperability among existing implementations, which includes a recognition of the fact that different engines have different implementational constraints. From what I seen you do that admirably, so this isn't any criticism of the way you operate, only one of your "not my problem" comment ;-) |
| 00:18 | <bholley> | *from what I've seen |
| 00:33 | <zewt> | gar, random mozilla.org stuff down so the last three random things I've tried to do stopped short |
| 00:34 | <zewt> | google cache go |
| 01:09 | <zewt> | heh uh joy |
| 01:10 | <zewt> | it looks like safari nightlies treat Content-Disposition as UTF-8, and other headers as raw data |
| 01:10 | <zewt> | (chrome stable just treats them all as UTF-8) |
| 09:52 | <zcorpan> | MikeSmith: i get 403 Forbidden for /ws/set-cookie - http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/cookies/002.html |
| 09:53 | <zcorpan> | MikeSmith: did i break the handler? or is something else wrong? |
| 10:04 | <MikeSmith> | zcorpan: taking a look now |
| 10:06 | <MikeSmith> | hm unfamiliar error in the logs |
| 10:08 | <MikeSmith> | ok that's unrelated |
| 11:14 | <MikeSmith> | zcorpan: mod_pywebsocket: web_socket_do_extra_handshake raised exception for /ws/set-cookie: list index out of range |
| 11:14 | <zcorpan> | ah, so i screwed up the handler |
| 11:15 | <zcorpan> | i guess it should check if there's a '?' in resource before trying to split on '?' |
| 11:15 | <zcorpan> | thanks |
| 11:15 | <annevk> | jgraham: https://bugs.webkit.org/show_bug.cgi?id=111602 |
| 11:18 | <jgraham> | annevk: Let's see if it goes anywhere :) |
| 11:22 | <zcorpan> | MikeSmith: i've pushed changes to set-cookie and set-cookie_http |
| 11:24 | <annevk> | zcorpan: out of interest, does WebSocket deal with HTTP auth? |
| 11:26 | <zcorpan> | 2. The server can perform additional client authentication, for |
| 11:26 | <zcorpan> | example by returning a 401 status code with the corresponding |
| 11:26 | <zcorpan> | WWW-Authenticate header field as described in [RFC2616]. |
| 11:27 | <zcorpan> | don't remember if it was implemented in presto |
| 11:27 | <MikeSmith> | zcorpan: now getting "failed: Compressed bit must be 0 if no negotiated deflate-frame extension" |
| 11:28 | <zcorpan> | MikeSmith: wat :-| |
| 11:28 | <MikeSmith> | heh |
| 11:28 | <MikeSmith> | indeed |
| 11:28 | <zcorpan> | annevk: seems like a bad idea to support http auth for websocket |
| 11:29 | <zcorpan> | MikeSmith: at least now i get a different fail for the test: expected object "/ws_test_1362655837981.0.401557051934188=test/" but got "ws_testws_test_=test" |
| 11:30 | <MikeSmith> | yeah |
| 11:32 | <zcorpan> | i don't understand why the handler gives "Set-Cookie: ws_testws_test_=test; Path=/" |
| 11:32 | <annevk> | zcorpan: cookies though, kinda |
| 11:32 | <annevk> | zcorpan: too* |
| 11:32 | <zcorpan> | annevk: at least cookies don't show up a dialog for the user |
| 11:32 | <annevk> | zcorpan: if the server does that, does it require the client to do a new request basically? |
| 11:33 | <zcorpan> | annevk: yeah i guess |
| 11:33 | <annevk> | zcorpan: oooooh if that's the way HTTP auth for WebSocket theoretically works I sure hope nobody implements that |
| 11:33 | <annevk> | (because of the end-user dialog, not the other bit) |
| 11:34 | <zcorpan> | i don't think webkit shows up a dialog (if it supports auth at all), but presto might |
| 11:51 | <annevk> | HTTP auth is also a kind of undefined part of Fetch |
| 11:51 | <annevk> | if there's username/password in the URL, do you do two requests or just one... what if you set a custom Authorization header, ... |
| 12:34 | <jgraham> | Have to love "the Process document is silent [...] however the Team enforces" |
| 12:35 | <jgraham> | Not just Process, but unwritten Process! |
| 12:37 | <zcorpan> | MikeSmith: afaict, the query component isn't included in ws_resource in this server's setup. which makes it a bit hard to use it. |
| 12:38 | <annevk> | jgraham: if plh is in a good mood, you might get stuff done |
| 12:38 | <MikeSmith> | zcorpan: dunno how to fix that.. |
| 12:40 | <zcorpan> | http://code.google.com/p/pywebsocket/issues/detail?id=68&can=1&q=uri |
| 12:41 | <zcorpan> | was closed but kinda missed the point. argh |
| 12:43 | <zcorpan> | http://modpython.org/live/current/doc-html/pyapi-mprequest-mem.html - looks like 'args' would be the query string |
| 12:44 | <zcorpan> | if so i can fix it in the handler by using that directly |
| 13:18 | <zcorpan> | MikeSmith: i tried 'args' and 'parsed_uri[URL_QUERY]' on our websocket server but that didn't really work. i guess i can try it on w3c-test as well and see if it works there |
| 13:18 | <MikeSmith> | ok |
| 13:22 | <zcorpan> | MikeSmith: pushed |
| 13:24 | <MikeSmith> | PASS :) |
| 13:24 | <MikeSmith> | http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/cookies/002.html |
| 13:24 | <MikeSmith> | http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/cookies/001.html still failing though |
| 13:29 | <darobin_> | slightlyoff: any ETA on making NavCon public? |
| 13:34 | <slightlyoff> | Likely tomorrow |
| 13:34 | <darobin> | ah, cool |
| 13:34 | <zcorpan> | MikeSmith: yay! http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/constructor/016.html now also passes |
| 13:35 | <zcorpan> | MikeSmith: 001 passes for me |
| 13:35 | <darobin> | that saves me from searching for "mob enforcers with nail-removing plyers near Alex Russel" |
| 13:36 | <MikeSmith> | zcorpan: don't pass in FF |
| 13:36 | <MikeSmith> | nor in chromium |
| 13:36 | <MikeSmith> | for me |
| 13:36 | <MikeSmith> | only in Opera |
| 13:36 | <annevk> | got to leave how vague WebSocket with regards to cookies and authentication |
| 13:36 | <annevk> | love* |
| 13:37 | <zcorpan> | MikeSmith: yeah. i guess that indicates a bug in chrome and firefox |
| 13:37 | <MikeSmith> | expected object "/ws_test_1362663513149.0.9708405185480612=test/" but got "(none)" |
| 13:37 | <MikeSmith> | ok |
| 13:40 | <annevk> | Oh man. People still find my fixed positioning page and then ask advice how to make it work in Internet Explorer 9, which supports CSS fixed positioning! |
| 13:40 | <annevk> | Apparently, IE9 does not support it if you don't include <!doctype html> at the top, which I advised... |
| 13:41 | <annevk> | (Euhm, I advised adding then, and then, "after a few times", it worked...) |
| 13:41 | <annevk> | s/then/that/ |
| 13:42 | <slightlyoff> | darobin: lucky for me you can't spell my last name :-) |
| 13:42 | <darobin> | damn, foiled again! |
| 13:46 | <jgraham> | (or pilers) |
| 13:47 | <jgraham> | (although it seems that some people consider plyers to be a variant spelling) |
| 13:47 | <darobin> | possibly more so than "pilers" |
| 13:47 | <jgraham> | Hah |
| 13:48 | <jgraham> | Well I have never been able to type |
| 13:48 | <darobin> | but hey, I'm not the native speaker in this conversation |
| 13:48 | <jgraham> | But you have a reputation to maintain |
| 13:48 | <darobin> | do I? I hope it's not mine because I likely suck at that job |
| 13:50 | <zcorpan> | yay! all cookie tests pass in opera now. finally |
| 13:54 | <jgraham> | Finished massaging the results then? ;) |
| 13:58 | <zcorpan> | yeah. for the last two tests i just removed a "!" to make them pass |
| 13:58 | <zcorpan> | if i want to change the timeout for an async test, do i need to include a title? async_test(func, title, settings) ? |
| 13:59 | <zcorpan> | looks like it from the code |
| 14:25 | <SimonSapin> | m |
| 14:32 | <jgraham> | zcorpan: Not really, you can pass null and it will use document.title |
| 14:32 | <jgraham> | But I agree that it should change so that the second argument can also be an options object |
| 14:40 | <zcorpan> | jgraham: ok |
| 14:48 | <zcorpan> | jgraham: do we want assert_greater_than in testharness? |
| 14:49 | <jgraham> | zcorpan: Yes, I have been meaning to add that. I guess we need all of assert_greater_tahn, assert_greater_than_equal, and s/greater/less/ in both |
| 14:50 | <zcorpan> | assert_gt, assert_gte etc maybe? |
| 14:51 | <jgraham> | This is why I have been holding off :) But no, we haven't used abbreviations like that elsewhere |
| 14:51 | <zcorpan> | ok. i'll go ahead and add them now |
| 14:51 | gsnedders | remembers agreeing to implement them before when he needed them, but then uni happened. |
| 14:51 | <jgraham> | (probably someone will soon want assert_approx_greater_than or something) |
| 14:52 | <zcorpan> | for approx_greater_than you can just reduce what you expect |
| 14:52 | <zcorpan> | and use greater_than |
| 14:52 | <jgraham> | It would have been nice to have a different design where you did something like assert_relates("eq", expected, actual) or something |
| 14:53 | <jgraham> | and invert() |
| 14:54 | <zcorpan> | -_- now you're making me consider not implementing it |
| 14:54 | <jgraham> | Well that ship sailed |
| 14:54 | <jgraham> | Maybe one day we should consider a V2 API |
| 14:55 | <jgraham> | But at the moment I think just doing the obvious thing and living with the extra api surface area would be best |
| 14:55 | <zcorpan> | where's the repo for testharness these days? |
| 14:55 | <zcorpan> | https://dvcs.w3.org/hg/resources/ ? |
| 14:56 | <jgraham> | No, the W3c one on github |
| 14:56 | <jgraham> | Make a pull request, please |
| 15:01 | <marcosc> | when using a datalist, how does one capture the event for when an option is selected? |
| 15:04 | <jgraham> | hah |
| 15:04 | <annevk> | marcosc: <input oninput> |
| 15:05 | <jgraham> | Apparently in Opera that triggers every time you move through the list |
| 15:06 | <annevk> | clone Opera or rebel Opera? |
| 15:06 | <jgraham> | (this question was being discussed here — i.e. in my office — earlier; I wonder if marcosc asking is independent of that) |
| 15:06 | <marcosc> | yeah, that's not really what you would want |
| 15:06 | <jgraham> | rebel alliance Opera |
| 15:06 | marcosc | was listening through a special listening device to everything that is said in jgraham's office |
| 15:07 | <jgraham> | Well possibly zcorpan spoke to you about it for some reason. Stranger things have happened :p |
| 15:08 | <zcorpan> | i discussed this with jeppe earlier today |
| 15:09 | <zcorpan> | i didn't discuss it with marcosc :-) |
| 15:09 | <jgraham> | Fair enough :) |
| 15:09 | jgraham | writes down "law of large numbers" |
| 15:10 | <zcorpan> | annevk: presto. webkit and gecko fire input when something is selected from the dropdown, which seems better |
| 15:10 | <annevk> | Presto had the same problem with <input type=email>'s initial implementation from bratell so that bug has been there since 2006 and back then we had devised the fix... |
| 15:10 | <marcosc> | annevk: fwiw, that even does not fire in Chrome or FF |
| 15:11 | <zcorpan> | my recommendation to jeppe was using a timeout from 'input' if what you want to do is heavy (like XHR) |
| 15:11 | <annevk> | marcosc: at all or just not for a <datalist> selection? |
| 15:11 | <zcorpan> | marcosc: input fires in chrome and firefox when i tested it earlier today |
| 15:11 | <marcosc> | this is my test: x = document.querySelector("datalist") |
| 15:12 | <annevk> | marcosc: data:text/html,<input oninput=alert(1)> wfm |
| 15:12 | <marcosc> | x.oninput = function(e){console.log(e)} |
| 15:12 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2135 |
| 15:12 | <zcorpan> | marcosc: it's fired on <input> |
| 15:12 | <zcorpan> | not datalist |
| 15:12 | <annevk> | data:text/html,<input oninput=alert(1) list=x><datalist id=x><option>test also fires |
| 15:12 | <marcosc> | ah, ok |
| 15:13 | <marcosc> | got confused |
| 15:13 | <jgraham> | That also confused Jeppe |
| 15:13 | <jgraham> | FWIW |
| 15:13 | <marcosc> | I expected the datalist also receive an event |
| 15:14 | <marcosc> | well, not also, but the place where the event would go |
| 15:16 | <annevk> | it's not being mutated |
| 15:16 | <annevk> | it's just a data source |
| 15:16 | <marcosc> | right, but I was expecting an click event or some kind of "onselect" |
| 15:16 | <jgraham> | It seems like a reasonable confusion to me |
| 15:16 | <jgraham> | If you imagine that the datalist is the thing that you actually see rendered |
| 15:16 | <zcorpan> | jgraham: should i change one of the apisample files? |
| 15:17 | <marcosc> | because, conceptually, what I am seeing on screen is a drop down box representing the <datalist> and the <options> |
| 15:17 | <jgraham> | zcorpan: If you like that would be nice |
| 15:17 | <zcorpan> | jgraham: which one? |
| 15:18 | <marcosc> | annevk: another issue, the event does not contain a reference to the <option> element |
| 15:18 | <jgraham> | The first one I guess? |
| 15:19 | <zcorpan> | yeah |
| 15:19 | <jgraham> | darobin: "and I even think it can be done relatively fast" - famous last words there :) |
| 15:19 | <darobin> | yeah I know |
| 15:19 | <darobin> | but |
| 15:19 | <marcosc> | annevk: my use case is, <option value="some thing" data-key="somekey">. I need to get the key of the option that was selected to then populate other form items. |
| 15:19 | <darobin> | the fact is that I've already been working on it :) |
| 15:19 | <darobin> | things are faster when they've been done (at least in part) |
| 15:20 | <annevk> | marcosc: does <option value=key>val</option> not work? |
| 15:20 | <jgraham> | But that means we can't have a language flamewar first :p |
| 15:20 | <annevk> | marcosc: I guess not... |
| 15:20 | <marcosc> | annevk: otherwise, I need to use the value as a CSS selector |
| 15:21 | <marcosc> | datalist[value='the value'] |
| 15:21 | <marcosc> | err, ad an option in there |
| 15:21 | <marcosc> | datalist > option [value='the value'] |
| 15:21 | <annevk> | marcosc: so <datalist> is just providing combobox options, but it's free entry so if the user types in "test" it's equivalent |
| 15:21 | <marcosc> | yes, exactly. |
| 15:21 | <annevk> | marcosc: so you really need a mapping from the <input>, not the <datalist> |
| 15:21 | <annevk> | marcosc: <datalist> is just for <input> hints and autocompletion |
| 15:22 | <marcosc> | right, but with a little bit more power (i.e., returning the element that was selected), you can do a lot of more cool things |
| 15:22 | <annevk> | I just explained why that doesn't work well |
| 15:23 | <marcosc> | ok, np. Thanks for your help annevk! :) |
| 15:37 | <zcorpan> | jgraham: hmm, my new apisample tests that are expected to fail are passing. :-( is the impl of assert_greater_than not just assert(typeof actual === "number",...); assert(actual > expected,...); ? |
| 15:38 | <jgraham> | That sounds right |
| 15:39 | <zcorpan> | i don't understand why the test passes. assert_greater_than(10, 11, "10 is not greater than 11"); |
| 15:39 | <zcorpan> | oh wait |
| 15:39 | <zcorpan> | c/p error in apisample... |
| 15:41 | <zewt> | (tip: once you have inequalities in assertion methods, it's nicer to have assert_ge, eq, ne, gt than to spell them all out) |
| 15:42 | <jgraham> | Yeah, but I'm not sure that assert_equals and assert_gt makes sense |
| 15:42 | <zewt> | though half the time I end up writing assertTrue(2 > 1), since being able to have the resulting values in an error message isn't worth the loss of readability to me |
| 15:42 | <zewt> | (with test suites in general, not this API specifically) |
| 15:43 | <zewt> | jgraham: possibly a dumb question since I don't know the API you're working on, but why wouldn't assert_equals make sense (if assert_greater_than does)? |
| 15:44 | <jgraham> | zewt: assert_equals exists |
| 15:44 | <zewt> | but doesn't make sense? :) |
| 15:44 | <jgraham> | Adding new asserts, follwoing the "full words" naming convention makes more sense than having some full words and some abbreviated |
| 15:44 | <zewt> | parse error? i read "things that don't make sense: assert_equals, assert_gt" |
| 15:45 | <jgraham> | So assert_gt doesn't make sense given the current API |
| 15:45 | <zcorpan> | we should have ass_gt |
| 15:45 | <jgraham> | Right, I meant the combination doesn't make sense, not the two individuallly |
| 15:45 | <zcorpan> | ok now i've fixed all c/p errors i think, at least i'm seeing the results i expect |
| 15:46 | <zewt> | wish there was a clever way to be able to write assert(a > b && c()), then pick apart the expression and dumb the symbols if it's false |
| 15:47 | <zewt> | so it could just say "expected true: 2 > 1 && 0" |
| 15:47 | <zewt> | oh well. heh |
| 15:49 | <jgraham> | I think python's node module tries to do that by inspecting the AST or something |
| 15:49 | <jgraham> | (if you turn on the right output option) |
| 15:50 | <jgraham> | *nose |
| 15:51 | <zewt> | cute, i use that but haven't seen that option |
| 15:51 | <zewt> | not that we'll ever get anything that low-level in JS |
| 15:51 | <zcorpan> | jgraham: pull request sent. i hope i clicked the right buttons. :-) |
| 15:56 | <jgraham> | zcorpan: Looks fine, but oh gosh is the order of the arguments confusing |
| 15:57 | <jgraham> | assert_less_than(10, 11) -> true |
| 15:57 | <zcorpan> | jgraham: what's confusing? |
| 15:58 | <zcorpan> | 10 < 11 -> true |
| 15:58 | <jgraham> | it's confusing because I read it as assert less than 10, 11 |
| 15:58 | <jgraham> | But it's consistent with the other functions and with other libraries |
| 15:59 | <zcorpan> | i don't follow, but if it's consistent with everything else it should be fine :-P |
| 15:59 | <darobin> | you want ObjC there, assert:10 lessThan:11 :) |
| 15:59 | <jgraham> | Well you could do that in javascript too, sort of |
| 16:00 | <darobin> | yes |
| 16:00 | <jgraham> | assert(actual, {operator:expected}) |
| 16:00 | <darobin> | assert(10).lessThan(11) |
| 16:00 | <jgraham> | Mine is less ugly :p |
| 16:00 | <zewt> | jgraham: the weird order is one reason I don't like test methods like that; give me infix, please |
| 16:00 | <jgraham> | assert(10 {lessThan:11}) |
| 16:00 | <zcorpan> | 10.lessThan(11) ? :-P |
| 16:01 | <zewt> | zcorpan: are you leaking Ruby into the channel? |
| 16:01 | <zewt> | D: |
| 16:01 | <zewt> | i guess that's not worse than objc, heh |
| 16:01 | <jgraham> | Ruby people would start making all sorts of claims about how it was readable as normal english, and you could replace specifications with testsuites |
| 16:01 | <darobin> | I don't know if this specific condition is supported with expect.js would have something like expect(10).to.be.less.than(11) |
| 16:02 | <zewt> | i really wish javascript had named arguments; assert(10, lessThan=11) |
| 16:02 | <jgraham> | Before going on to say "also, wasn't COBOL a great idea" |
| 16:02 | <zewt> | jgraham: careful, every time I make fun of Ruby they come out of the woodwork and attack me |
| 16:02 | darobin | points at ruby, laughs! Runs away |
| 16:03 | <jgraham> | Except, ironically, they wouldn't so the last bit. |
| 16:03 | <jgraham> | *do |
| 16:03 | <zcorpan> | MikeSmith: does testharness.js get synced to w3c-test.org automatically? |
| 16:03 | <zewt> | at least on stackoverflow, ruby people seemed to take the most righteous offense to the slightest criticism of their holy language, heh |
| 16:04 | <zcorpan> | MikeSmith: http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/constructor/014.html uses a new assertion function |
| 16:04 | <jgraham> | zcorpan: So are the websockets tests done now? |
| 16:05 | <MikeSmith> | zcorpan: it does, I'm pretty sure, but only through a cron jub that I think we have set up to run only every 10 minutes |
| 16:05 | <zcorpan> | jgraham: don't know, i'm going through them and checking that they're OK |
| 16:05 | <MikeSmith> | zcorpan: I will ssh in and look from teh filesystem |
| 16:05 | <zcorpan> | MikeSmith: oh if it gets updated every 10 minutes i can wait 10 minutes |
| 16:06 | <jgraham> | zcorpan: Thanks |
| 16:07 | <MikeSmith> | zcorpan: timestamps on all the files there say Feb 9 |
| 16:07 | <MikeSmith> | but I can just force an update from the console |
| 16:08 | <MikeSmith> | jgraham: you mean in http://w3c-test.org/resources/ right? |
| 16:08 | <jgraham> | MikeSmith: I mean what now? |
| 16:08 | <jgraham> | MikeSmith: I imagine that's what zcorpan means |
| 16:09 | <jgraham> | or at least where he expectes testharness.js to be updated to |
| 16:09 | <jgraham> | So if you really meant to ask me something, I need more context :) |
| 16:09 | <MikeSmith> | yeah it seems I don't have it set up to sync yet |
| 16:09 | <MikeSmith> | will do it right now |
| 16:12 | <zcorpan> | MikeSmith: ws/protocol_array gives a 404 response. :-/ |
| 16:15 | <MikeSmith> | will check that next |
| 16:15 | <MikeSmith> | for now latest testharness.js is pulled and I added to cron job to sync it |
| 16:18 | <MikeSmith> | zcorpan: I don't see any protocol_array in https://dvcs.w3.org/hg/webapps/file/default/WebSockets/tests/submissions/Opera |
| 16:18 | <zcorpan> | MikeSmith: thanks! 014 passes |
| 16:18 | <zcorpan> | MikeSmith: i have an protocol_array_wsh.py file in my working copy |
| 16:19 | <MikeSmith> | ah |
| 16:20 | <MikeSmith> | zcorpan: well, I see on the server -rwxr-xr-x 1 rsshuser rsshuser 347 Mar 7 15:58 protocol_array_wsh.py |
| 16:20 | <jgraham> | It looks like it has a syntax error? |
| 16:21 | <jgraham> | Hard to tell from the dvcs display though |
| 16:21 | <jgraham> | Line 12 |
| 16:21 | <zcorpan> | jgraham: is http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/interfaces/WebSocket/bufferedAmount/005.html correct? http://dev.w3.org/2006/webapi/WebIDL/#es-attributes seems to say it should be configurable... |
| 16:21 | zcorpan | looks at _array |
| 16:22 | <zcorpan> | bogus indentation, looks like |
| 16:22 | <jgraham> | zcorpan: I guess those tests for configurability are wrong? Probably WebIDL changed |
| 16:23 | <zcorpan> | jgraham: yeah. thanks |
| 16:24 | <zcorpan> | MikeSmith: i fixed protocol_array (i hope!) |
| 16:33 | <MikeSmith> | zcorpan: Ok copied over |
| 16:33 | <zcorpan> | PASS. thanks MikeSmith! |
| 16:34 | <MikeSmith> | super |
| 16:35 | <zcorpan> | jgraham: heh what happened here? http://w3c-test.org/webapps/WebSockets/tests/submissions/Opera/interfaces/WebSocket/readyState/005.html :-) |
| 16:37 | <jgraham> | zcorpan: ctrl-x ctrl-s = save in emacs :) |
| 16:38 | <zcorpan> | ah |
| 16:59 | <annevk> | So Safari/Chrome implement the "fetch from an origin" thingie for at least navigation by means of <form> submission |
| 16:59 | <marcosc> | so, how would one get the browser to display the value of "setCustomValidity()"? I expected it to be displayed just like the error message that pops up when a required field is missing |
| 16:59 | <marcosc> | ? |
| 16:59 | <annevk> | Firefox and Internet Explorer do not |
| 17:00 | <annevk> | Rebel Opera doesn't either |
| 17:00 | <zcorpan> | jgraham: i'll have to continue tomorrow, i haven't checked everything. but it's getting close now |
| 17:01 | <zcorpan> | thanks for your help MikeSmith and jgraham |
| 17:01 | <dglazkov> | good morning, Whatwg! |
| 17:01 | marcosc | gives dglazkov a morning hug and kiss! |
| 17:46 | <Hixie> | bholley: the difference with other constraints is that those don't affect existing features, though, right? |
| 17:46 | <Hixie> | bholley: whereas here we're talking about something that affects a long-standing, and rather subtle and complicated, aspect of the platform |
| 19:55 | <Hixie> | anyone have opinions on how we should define "initial about:blank"? |
| 19:56 | <Ms2ger> | hsivonen does, I bet |
| 20:04 | <ronaldmansveld> | Hixie: in what context? Cause I'd say it would be just a blank document, without any sourcecode, thus an empty DOM-tree etc. |
| 20:04 | <ronaldmansveld> | Hixie: I'd have to check on what is currently implemented as about:blank though in browsers |
| 20:05 | <ronaldmansveld> | Hixie: But pretty sure chrome serves an empty document (which then gets autofilled with empty head and body tags) |
| 20:05 | <Ms2ger> | ronaldmansveld, I'm not saying you shouldn't... But it may waste away several years of your life |
| 20:06 | <ronaldmansveld> | hahaha, then I think i might pass on that one ;) |
| 20:07 | <ronaldmansveld> | (even though by now my interest has been sparked to see *what* browsers actually serve when about:blank is requested :P ) |
| 20:07 | <gsnedders> | ronaldmansveld: It's how it loads synchronously and the like that's complex, not what it is. |
| 20:09 | <ronaldmansveld> | but is the way of loading not independent of how you should/would define what "initial about:blank" is? (again, depending on context) |
| 20:09 | <gsnedders> | Well, initial about:blank is identical in content to the non-initial variant. It's the loading that differs. |
| 20:11 | <ronaldmansveld> | OK, bad timing for wifi to go down |
| 20:11 | <jgraham> | No, good timing, now you don't need to think about about:blank anymore |
| 20:12 | <ronaldmansveld> | And given Ms2ger's massage I don't think i'd be a good idea to actually obtain that knowledge :P |
| 20:12 | <ronaldmansveld> | hahaha, indeed |
| 20:13 | <jgraham> | ronaldmansveld: Everything you need to know about about:blank you can learn from the strapline of https://twitter.com/hsivonen |
| 20:14 | <ronaldmansveld> | wow, if someone actually can make a living out of it, i'm out |
| 20:14 | <ronaldmansveld> | as in: intrigued, but too busy to get myself into that |
| 20:14 | <Ms2ger> | Well, hsivonen makes a living of a number of horrible misfeatures :) |
| 20:14 | <jgraham> | Ms2ger: We all do |
| 20:14 | <jgraham> | Well not you so much |
| 20:15 | <ronaldmansveld> | Not yet, but I'm willing to learn a lot and think along ;) |
| 20:15 | <Ms2ger> | Yeah, I make nothing off a number of horrible misfeatures :) |
| 20:15 | <jgraham> | I meant Ms2ger |
| 20:15 | <ronaldmansveld> | haha, it's OK |
| 20:15 | <Ms2ger> | But hsivonen has been particularly successful at picking terrible ones, it seems :) |
| 20:16 | <gsnedders> | Normally without realizing how bad they are. |
| 20:16 | <gsnedders> | Things that appear simple. |
| 20:16 | <gsnedders> | Things that really are anything but simple. |
| 20:17 | <jgraham> | Pretty much anything to do with loading documents for example |
| 20:22 | <ronaldmansveld> | btw, how did you all get involved into specs? (writing etc.) |
| 20:22 | <jgraham> | Spent too long here |
| 20:23 | <Ms2ger> | Joined www-style one day in 2007 |
| 20:25 | <jgraham> | Well yes, I guess my actual story starts long before #whatwg |
| 20:25 | <jgraham> | But yeah, reading W3C mailing lists is how most people get started |
| 20:25 | <Ms2ger> | "I was born" |
| 20:25 | <jgraham> | "My parents were born" |
| 20:26 | <Ms2ger> | "Primordial soup" |
| 20:26 | <Ms2ger> | Might as well take big steps :) |
| 20:26 | <jgraham> | "Inflationary expansion" |
| 20:26 | <Ms2ger> | "Boom" |
| 20:31 | <ronaldmansveld> | But was it like the urge to solve existing problems? Or just plain curiousity? |
| 20:37 | <jgraham> | Curiosity I guess |
| 20:47 | <Hixie> | ronaldmansveld: i mean, when should an about:Blank document stop being considered the "initial" one, for the purposes of e.g. the logic in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17093 |
| 20:50 | <ronaldmansveld> | Hixie: I don't know that much about the subject, so I'll just give my opinion as a user/webdeveloper: |
| 20:51 | <ronaldmansveld> | when doing a document.open() (either via JS or opening a new tab), I consider the about:blank to be like a placeholder for the page I'm actually going to open |
| 20:51 | <ronaldmansveld> | so I don't see why that should be in my history, not even when pushing the back-button |
| 20:52 | <ronaldmansveld> | But as soon as anything happens to the (I presume) empty DOM-tree of about:blank, it's not the placeholder anymore, so at that point I would expect it to be pushed into history |
| 20:52 | <ronaldmansveld> | (if that makes sense to you) |
| 20:53 | <ronaldmansveld> | it's like about:blank is null. It will remain null untill it's changed |
| 20:53 | <ronaldmansveld> | (or replaced for that matter) |
| 20:54 | <ronaldmansveld> | (if anyone thinks i'm talking BS here, please do say so ;) ) |
| 20:59 | <Hixie> | ronaldmansveld: yeah, it's just working out when "anything happens" |
| 21:01 | <ronaldmansveld> | I guess that 'anything' would be any alteration to the DOM-tree |
| 21:01 | <Hixie> | define "alteration" |
| 21:01 | <ronaldmansveld> | since replacing the about:blank with another page will automatically insert a position in history |
| 21:01 | <Hixie> | does adding a property to the prototype of the <body> element count? |
| 21:01 | <ronaldmansveld> | hmm, tough one |
| 21:02 | <Hixie> | same question, for every possible change :-) |
| 21:02 | <ronaldmansveld> | I guess 'does the user notice?' isn't a valid point here? :P |
| 21:02 | <ronaldmansveld> | (meaning: 'does the user notice' would be the threshold) |
| 21:03 | <Hixie> | would you be the one to ask the user each time if he noticed? :-) |
| 21:03 | <ronaldmansveld> | well, let's take it even one step back: |
| 21:03 | <ronaldmansveld> | about:blank should be a null document |
| 21:03 | <ronaldmansveld> | as in: empty, no sourcecode, empty DOM-tree, no elements, no nothing |
| 21:03 | <Hixie> | that is incorrect |
| 21:04 | <ronaldmansveld> | so it's impossible to add a property to the body element |
| 21:04 | <Hixie> | for compat reasons it has at least an <html> element and a <body> element |
| 21:04 | <Hixie> | and a Document object |
| 21:04 | <Hixie> | and a Window object |
| 21:04 | <Hixie> | and all the others, like Location, Navigator, etc |
| 21:04 | <ronaldmansveld> | and with that, complexity enters |
| 21:05 | <ronaldmansveld> | I see |
| 21:05 | <Hixie> | i should go eat lunch, bbiab |
| 21:05 | <ronaldmansveld> | enjoy lunch, I'll think about this some more |
| 21:21 | <zewt> | bleh, i want a way to have a self-closing element not be |
| 21:26 | <jgraham> | zewt: XML? :p |
| 21:33 | <esprehn> | when is Anne usually around? |
| 21:40 | <Hixie> | esprehn: as far as i can tell, mostly when i'm not, unfortunately for me :-) |
| 21:41 | <esprehn_> | yeah |
| 21:45 | <ronaldmansveld> | Hixie: I think I've come a bit further |
| 21:45 | <JonathanNeal> | I have seen that single html pages are referred to as documents. What are a collection of html pages referred to? A corpus? |
| 21:46 | <Hixie> | JonathanNeal: sites? |
| 21:46 | <Hixie> | JonathanNeal: depends what the collection is |
| 21:46 | <Philip`> | JonathanNeal: HTML books |
| 21:47 | <ronaldmansveld> | Hixie: so just give a shout whenever you're ready |
| 21:47 | <jgraham> | I thought the group noun for markup was "clusterfuck" |
| 21:48 | <JonathanNeal> | Well, we're all agreed then. Section < Document < Clustersitebookfuck. |
| 21:48 | <JonathanNeal> | dot com |
| 21:48 | <Hixie> | ronaldmansveld: sure |
| 21:48 | <JonathanNeal> | Hixie: you would feel confident that it's a "Site"? |
| 21:49 | <JonathanNeal> | In the same generic terms as "Document". |
| 21:49 | <Hixie> | JonathanNeal: depends. if you collect the documents from two sites, obviously the collection isn't a site |
| 21:49 | <Hixie> | JonathanNeal: without knowing more about what the collection is, i'd call it a "collection" :-) |
| 21:50 | <Hixie> | ronaldmansveld: looks like existing places in the spec that deal with this use the term "if the child browsing context's session history contained only one Document when the process the iframe attributes algorithm was invoked, and that was the about:blank Document created when the child browsing context was created" |
| 21:50 | <Hixie> | ronaldmansveld: (by "sure" i meant "i'm ready") |
| 21:50 | <ronald_mansveld> | Hixie: I did a quick check to see what browser would give as actual source for about:blank. FF and Chrome show an empty document (no sourcecode), Opera wouldn't open any sourcecode, so I presume it's empty as well, IE10 shows the source as being <html></html> |
| 21:51 | <ronald_mansveld> | In the inspectors, this does become a document with an empty <head> and empty <body>, like you said for compat |
| 21:51 | <JonathanNeal> | ronald_mansveld: i too have noticed that about:blank is usually an empty document. |
| 21:51 | <jgraham> | ronald_mansveld: So, the essential imformation is that about blank the document is the result of parsing the empty string |
| 21:51 | <ronald_mansveld> | indeed |
| 21:51 | <Hixie> | ronald_mansveld: that part of the question is well established, yes |
| 21:52 | <jgraham> | But that doesn't say much about its loading or intereaction with session history |
| 21:52 | <ronald_mansveld> | with IE being the exception, since it doesn't serve an empty string ;) |
| 21:52 | <JonathanNeal> | In Chrome, under Resources, there is no document listed for about:blank. |
| 21:52 | <JonathanNeal> | In Network, no requests. |
| 21:52 | <JonathanNeal> | No Source, etc. |
| 21:52 | <ronald_mansveld> | I'd say: this parsing of an empty string should be considered the 'base'. |
| 21:53 | <ronald_mansveld> | just that base will not insert anything into history, as if it has never existed |
| 21:53 | <ronald_mansveld> | so you can't click the back-button to get back to that state |
| 21:53 | <Hixie> | jgraham: actually the real initial about:blank, per spec, doesn't even involve an HTML parser |
| 21:53 | <ronald_mansveld> | the next question would be: which changes to this 'base' should trigger insertion into history? |
| 21:54 | <Hixie> | ronald_mansveld: based on similar situations in the spec so far, it looks like nothing would trigger that |
| 21:54 | <ronald_mansveld> | you could opt for all, since a change is a change, which makes it different from the 'base' |
| 21:54 | <ronald_mansveld> | but you could also restrict it to changes that trigger a repaint |
| 21:54 | <JonathanNeal> | ronald_mansveld: i can navigate back to about:blank, and before, and after. |
| 21:54 | <JonathanNeal> | at least, in Chrome. |
| 21:55 | <ronald_mansveld> | I noticed you can indeed in chrome, but it's not behaviour i'd expect (since I consider about:blank to be some kind of 'null' document) |
| 21:56 | <Hixie> | ronald_mansveld: resizing the window results in a repaint... |
| 21:56 | <ronald_mansveld> | Hixie: it may, but resizing the window is not a change of the document that triggers a repaint ;) |
| 21:57 | <ronald_mansveld> | and does resizing the window on an empty document really trigger a repaint? |
| 21:57 | <ronald_mansveld> | arent' browsers 'smart' enough to know beforehand that there are no elements to repaint, so they don't even have to trigger it? |
| 21:58 | <jgraham> | You *really* don't want to try history to painting |
| 21:58 | <Hixie> | resizing the window changes the body element's offsetWidth |
| 21:58 | <Hixie> | how is that not a change to the document? |
| 21:58 | <Hixie> | and it fires an event |
| 21:58 | <Hixie> | there's all kinds of stuff that happens when you resize |
| 21:59 | <ronald_mansveld> | hmm, there goes my idea |
| 22:00 | <Hixie> | i'll just be consistent with the other places that do this |
| 22:00 | <ronald_mansveld> | but Hixie , if about:blank (per spec, like you stated) doesn't involve an HTML parser, why the need for the empty compat head and body? |
| 22:01 | <Hixie> | how are the two related? |
| 22:01 | <Hixie> | compat needs are driven by what existing pages depend on |
| 22:01 | <Hixie> | whether something involves a parser is driven just by how the spec is written |
| 22:01 | <ronald_mansveld> | well, if nothing gets parsed, I don't see why the elements should be there |
| 22:02 | <Hixie> | because pages rely on them being there |
| 22:02 | <Hixie> | jgraham: do you know what i should do when i have a bug blocked on getting feedback from zcorpan, given that i don't want to lose track of it? |
| 22:03 | <Hixie> | (if i didn't mind losing track of it, i'd reassign it) |
| 22:08 | <jgraham> | Hixie: He is around again now (not *right* now), so maybe he can unblock you? |
| 22:10 | <Hixie> | jgraham: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18460 |
| 22:11 | <ronald_mansveld> | Hixie: if I read your change correctly, this means that about:blank will not create an entry in history, as long as it was not changed at all |
| 22:12 | <ronald_mansveld> | so any change (including ie. resizing the browserwindow), will result in about:blank being added to history |
| 22:12 | <Hixie> | that wasn't my intent... what part of the change leads to that interpretation? |
| 22:13 | <Hixie> | anyone know what the status is with respect to file api and blob url revocation? |
| 22:13 | <ronald_mansveld> | <p>Otherwise, if the <span>browsing context</span>'s <span>session history</span> contains only |
| 22:13 | <ronald_mansveld> | + one <code>Document</code>, and that was the <code>about:blank</code> <code>Document</code> |
| 22:13 | <ronald_mansveld> | + created when the <span>browsing context</span> was created, then let <var title="">replace</var> |
| 22:13 | <ronald_mansveld> | + be true.</p> |
| 22:13 | <Hixie> | am i still supposed to do https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 ? |
| 22:13 | <jgraham> | Hixie: Oh, that bug looks rather irrelevant. I think that XSLT should probably define how to produce HTML with XSLT rather than HTML monkeypatching it |
| 22:13 | <Hixie> | jgraham: well, we already monkeypatch it a bit |
| 22:13 | <jgraham> | Sure |
| 22:13 | <Hixie> | jgraham: apparently we broke xslt when we changed the html namespace |
| 22:13 | <Hixie> | can't work out why, but that's another issue |
| 22:14 | <ronald_mansveld> | I read this as: replace will be true if it contains 1 Document, which is the same as the about:blank Document on creation of the context. |
| 22:14 | <jgraham> | Actually broke, or theoretically broke? |
| 22:14 | <jgraham> | I mean did it affect any browsers? |
| 22:14 | <ronald_mansveld> | any change will make it *not* the same anymore, thus replace will be false |
| 22:14 | <Hixie> | ronald_mansveld: right? even if you mutate the Document's children, it's still the same Document |
| 22:14 | <Hixie> | ronald_mansveld: if you cut your hair, you don't stop being ronald_mansveld :-) |
| 22:14 | <Hixie> | jgraham: theoretically, i think |
| 22:14 | <ronald_mansveld> | I'm still ronald_mansveld , but am I the same ronald_mansveld as I was before? |
| 22:14 | <jgraham> | (I suspect browsers are hopelessly incompatible in the details of xslt anyway) |
| 22:15 | <Hixie> | ronald_mansveld: in the case of the spec, a Document is the same Document even if you change all its properties |
| 22:15 | <Hixie> | ronald_mansveld: an object's identity is defined by te JS spec |
| 22:15 | <jgraham> | Anyway, if zcorpan doesn't notice, I can point him at the bug in the morning |
| 22:16 | <ronald_mansveld> | OK, if the definition of same has been defined elsewhere, and it implies what you meant, than I see no reason to oppose this :) |
| 22:18 | <jgraham> | Hixie: I guess we will find out if that navigation change works next time someone reimplements their document loading |
| 22:18 | <zewt> | i'm being thwarted by css today |
| 22:18 | <Hixie> | jgraham: fifteen years from now, then :-P |
| 22:18 | <jgraham> | which would be, ummm, well Servo I guess |
| 22:18 | <ronald_mansveld> | especially since in practice, if you do hand out a url to replace the about:blank with, nothing will (or should) happen to about:blank that would make a user go back to about:blank |
| 22:18 | <zewt> | background-clip: border-box doesn't change background-position: 100% to mean "bottom of the border" :| |
| 22:18 | <Hixie> | zewt: background-origin: border-box is what you want |
| 22:19 | <zewt> | ah, didn't see that since i was reading mdn CSS/background at the top (which only lists things that background is shorthand for) |
| 22:20 | <zewt> | <- playing the "make css do what an artist came up with in photoshop" game |
| 22:22 | <zewt> | (trying to put a left-aligned, fixed-size drop shadow underneath an element, which is something border-image apparently can't do) |
| 22:24 | <zewt> | bleh: think i'm going to have to fall back on another element, which is a pain since the graphic is affected by the input's :focus, so it's probably going to need JS |
| 22:26 | <ronald_mansveld> | zewt: maybe ::before and ::after can help you here? |
| 22:26 | <zewt> | hmm, i've never used them except to add text |
| 22:27 | <zewt> | (i can't even add children to an <input> in script? that's annoying) |
| 22:29 | <zewt> | (oh, I'm doing something stupid) |
| 22:30 | <jgraham> | Hixie: I don't know if anyone answered you (and I am too lazy to check), but zewt knows about the autorevocation stuff |
| 22:32 | <zewt> | (but apparently children of <input> aren't rendered; oh well, weird hack discarded) |
| 22:36 | <Hixie> | zewt: is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 still relevant? |
| 22:37 | <Hixie> | still no heycam |
| 22:37 | <Hixie> | hmm |
| 22:38 | <zewt> | Hixie: yes, though not up to date (anne and I talked a bit about it and I suspect URL parsing is approximately the right place that can live, now that we have a parsed-URL abstraction) |
| 22:39 | <Hixie> | well, the HTML APIs don't parse the URL right away, so it wouldn't be good to do it there |
| 22:39 | <Hixie> | or at least, not only there |
| 22:40 | <zewt> | the idea is to always parse the URL right away (or whatever the hook is), then stash the parsed URL until it's needed (eg. whenever "update the image data", etc. happen) |
| 22:40 | <zewt> | i can talk about this a bit more in an hour or so |
| 22:40 | <Hixie> | that doesn't work, since for compat we have to use the base url that's later, sometimes |
| 22:40 | <Hixie> | (e.g. <a href>) |
| 22:41 | <zewt> | could only do it for absolute urls, maybe |
| 22:41 | <zewt> | (sort of hacky, hmm) |
| 22:41 | <Hixie> | the whole thing is hacky |
| 22:41 | Hixie | is very much not a fan of this autorevokation thing |
| 22:42 | <zewt> | it's better than the manual one by far :) |
| 22:43 | <zewt> | Hixie: also, there are issues with non-autorevoke urls that this would deal with (iirc, since "update the image data" might happen sync or async, that would be exposed when updating to a blob URL that gets revoked immediately after assigning img @src) |
| 22:44 | <zewt> | eg. url = createObjectURL(blob); img.src = url; revokeObjectURL(url) works if it happens sync but not if it's async |
| 22:46 | <Hixie> | zewt: the whole revocation thing is problematic, yes |
| 23:05 | <esprehn> | gotta love manual memory management |
| 23:29 | <jamesr> | who owns https://www.w3.org/StyleSheets/TR/W3C-ED ? |
| 23:29 | <jamesr> | at the bottom it has this: background-image: url(http://www.w3.org/StyleSheets/TR/logo-ED); |
| 23:29 | <jamesr> | which produces mixed content if a spec referencing that stylesheet is loaded over https |
| 23:29 | <jamesr> | the logo is served over https |