| 03:17 | <linclark> | I see that the microdata dom api is being considered for removal? |
| 03:17 | <linclark> | is there a link with the reasoning? |
| 03:19 | <kennyluck> | huh? never heard of this info... |
| 03:20 | <linclark> | http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata-dom-api |
| 03:23 | <Hixie> | linclark: not being considered for removal by me, but no idea if anyone else is considering arguing to remove it |
| 03:23 | <linclark> | Hixie: ah, ok, good to know... thanks! |
| 03:23 | <Hixie> | linclark: at this point there's little chance it'll be removed from the whatwg html standard unless someone has a really good argument, e.g. "we tried implementing it in a browser and nobody used it" |
| 03:24 | <linclark> | yeah, it seemed strange that the rest of microdata was still yellow but that the API for doing anything with it was red |
| 03:26 | <xylron> | Hey, quick note: in the latest complete WHATWG editors draft, in the references section, the WebVTT reference has a heading that reads "[WEBWORKERS]". That looks like a copy and paste issue. |
| 03:26 | <Hixie> | linclark: oh is it marked as such in the spec? |
| 03:27 | <Hixie> | so it is |
| 03:27 | <Hixie> | apparently "lpeng564" changed it |
| 03:27 | <Hixie> | wonder who that is |
| 03:29 | <Hixie> | looks like that's the only change that account made |
| 03:29 | <Hixie> | weird |
| 03:30 | <zewt> | hacked by microdata haters |
| 03:31 | <Hixie> | the way the database is set up makes it pretty trivial for vandalism to be fixed on the backend |
| 03:31 | <Hixie> | (i never implemented the frontend since it's never been an issue) |
| 03:31 | <Hixie> | literally every change ever made is logged, i don't just change the state |
| 03:31 | <Hixie> | and to get the current state i just ask for the last change |
| 03:35 | <linclark> | Hixie: yeah, after I saw that it wasn't your email address, I thought it might be something like that |
| 03:36 | <Hixie> | i fixed it |
| 14:12 | <annevk> | http://www.youtube.com/watch?v=YXh9RQCvxmg#t=6m30s is so awesome |
| 14:12 | <annevk> | I should extract some part to use as an example somewhere |
| 15:39 | <Ms2ger> | <biesi> why is it that way? |
| 15:39 | <Ms2ger> | <Hixie> i don't understand the question |
| 15:39 | <Ms2ger> | <Hixie> it almost sounded like you were trying to obtain some sort of logical explanation for browser behaviour |
| 15:39 | <annevk> | that's an old one; still funny :) |
| 15:40 | <Ms2ger> | Yeah, 2006 :) |
| 16:11 | <annevk> | Ms2ger: do you think it would be fine to define the new methods as if they passed a DocumentFragment to our existing methods? |
| 16:11 | <Ms2ger> | Sure |
| 16:11 | <annevk> | Ms2ger: e.g. append("test", node) passes a DocumentFragment consisting of a Text node "test" and a node to concept-node-append |
| 16:12 | <annevk> | The alternative would be to rewrite cocnept-node-append and friends to deal with lists, but this model seems somewhat clearer |
| 16:12 | <annevk> | At least, to the extent I managed to think about it |
| 16:12 | <Ms2ger> | Yeah, DocumentFragments are little more than lists anyway |
| 16:13 | <annevk> | never mind, it does not work for DocumentType and such :( |
| 16:13 | <Ms2ger> | Sounds like a positive effect :) |
| 16:14 | <annevk> | I'm not sure why we should support document.append(DocumentType), but some people think we should |
| 16:14 | <annevk> | of course it also means document.append(DocumentType, Element) should work (if document does not have them), but that requires changes to the existing algorithm |
| 16:18 | <annevk> | maybe it should be like |
| 16:18 | <annevk> | * one argument: pass it on |
| 16:19 | <annevk> | * more than one argument: DocumentFragment it or throw "HierarchyRequestError" if it does not fit in a DocumentFragment |
| 16:19 | <annevk> | (and then if it did not throw, pass it on) |
| 16:19 | <annevk> | so you have the same limitations, just a cooler API |
| 16:21 | <annevk> | making algorithms more complex to support ancient legacy bestowed upon us by SGML seems overkill |
| 16:34 | <annevk> | so given that |
| 16:35 | <annevk> | node.prepend(x) -> concept-node-pre-insert x into node before node's first child |
| 16:35 | <annevk> | node.append(x) -> concept-node-append |
| 16:36 | <annevk> | node.before(x) -> concept-node-pre-insert x into node's parent before node |
| 16:37 | <annevk> | node.after(x) -> concept-node-pre-insert x into node's parent before node's next sibling |
| 16:38 | <annevk> | node.replace(x) -> concept-node-replace node with x within node's parent |
| 16:38 | <annevk> | node.remove() -> concept-node-remove node from node's parent |
| 16:39 | <annevk> | plus the appropriate null checks for parent |
| 19:36 | <AryehGregor> | annevk, SELECT user_name FROM user WHERE user_edit_count < 2 or similar. |
| 19:38 | <AryehGregor> | Hixie, BTW, "if [ ( !" is wrong because ( initiates a subshell. You probably want "if [ \( !" (if the [ command even allows grouping, never tried). |
| 19:38 | <Hixie> | aaah |
| 19:38 | <Hixie> | thanks |
| 19:38 | <AryehGregor> | Hmm, maybe not. |
| 19:38 | <AryehGregor> | [ in bash is a builtin. |
| 19:39 | <AryehGregor> | But I think it follows the same escaping rules as real commands. |
| 19:41 | <AryehGregor> | Yeah, seems to. |
| 21:38 | <bencc> | is the client required to send a UserAgent string when establishing a websocket connection? |
| 21:38 | <Hixie> | when i was writing the spec, it was required not to |
| 21:39 | <Hixie> | no idea what the spec says now though |
| 21:39 | <bencc> | why not to? |
| 21:39 | <bencc> | if you only send it once, why not send it? |
| 21:39 | <Hixie> | because it hurts small browsers |
| 21:40 | <bencc> | firefox sends the UseAgent while chrome doesn't |
| 21:40 | <bencc> | so if I need the user agent, I should send it myself after the connection? |
| 21:40 | <Hixie> | you should not need the user agent |
| 21:41 | <bencc> | if there is a bug, I want to know what browser cause it |
| 21:41 | <Hixie> | is there a bug? |
| 21:41 | <bencc> | there are always bugs |
| 21:42 | <bencc> | not with the websocket implementation but anything |
| 21:42 | <Hixie> | then file the bug with the browser vendor and have them fix it |
| 21:42 | <bencc> | :) |
| 21:42 | <Hixie> | working around the bug will just make matters worse |
| 21:42 | <Hixie> | on the long run |
| 21:42 | <bencc> | that's not what I meant |
| 21:43 | <Hixie> | but it's what i meant :-) |
| 21:43 | <bencc> | I want to have statistics about my users, to know what browsers they use |
| 21:43 | <Hixie> | why? |
| 21:43 | <Hixie> | it shouldn't make any difference to you |
| 21:43 | <bencc> | are you serious? |
| 21:43 | <Hixie> | yes |
| 21:43 | <bencc> | all browsers work 100% ? |
| 21:43 | <bencc> | no bugs? no missing features? |
| 21:44 | <Hixie> | missing features you can feature-test for, you don't need to know which browser it is |
| 21:44 | <Hixie> | bugs, you should ignore, and let the browser vendors fix it, instead of hacking around them |
| 21:44 | <Hixie> | certainly shouldn't sniff for the browser to work around them |
| 21:44 | <Hixie> | if you do that you will make it harder for them to fix the bug |
| 21:44 | <Hixie> | not to mention that it means you are prioritising certain browsers over others |
| 21:45 | <Hixie> | which gives smaller browsers a competitive disadvantage |
| 21:45 | <bencc> | I don't care about politics |
| 21:45 | <bencc> | I want my app to work |
| 21:46 | <Hixie> | this isn't politics, it's the good of the human race |
| 21:46 | <Hixie> | anyway, we're talking about hypotheticals here |
| 21:46 | <Hixie> | it's easier to discuss concrete cases |
| 21:47 | <Hixie> | hence my question: |
| 21:47 | <Hixie> | is there a bug? |
| 21:47 | <bencc> | so if a plane crash, the model is not important |
| 21:47 | <bencc> | just let the company fix it |
| 21:47 | <bencc> | they should guess it happened |
| 21:47 | <Hixie> | if you're building a plane on WebSocket then you need your head examined :-) |
| 21:47 | <smaug____> | :) |
| 21:48 | <bencc> | no, I'm building a web app and I put most of my time making it compatible with opera |
| 21:48 | <wilhelm> | Which of our many bugs are causing you trouble? |
| 21:48 | <bencc> | because most of the users in the world use it |
| 21:48 | <Hixie> | bencc: you shouldn't put your time into making your web app compatible with _any_ browser |
| 21:48 | <Hixie> | bencc: write to the spec, and if the browsers are buggy, file bugs with the browsers |
| 21:50 | <bencc> | that's exactly how gmail work |
| 21:50 | <Hixie> | i would definitely not recommend taking gmail as an example for how to build a web app |
| 21:50 | <bencc> | they implemented the chat and video with html5 5 years ago |
| 21:55 | <bencc> | should the browser show a warning when using secure websocket with self signed certificate? |
| 21:55 | <Hixie> | no, it should just disallow it from connecting |
| 21:56 | <bencc> | but browsers allow pages of self signed certificates with a warning |
| 21:57 | <Hixie> | yeah, that's dubious too. but at least they can put up an interstitial to explain to the user that they're about to have their identity stolen. |
| 21:58 | <bencc> | about feature detection, can I detect the websocket version on the client? |
| 21:58 | <bencc> | I know I can see the version on the server |
| 21:59 | <Hixie> | aw man, did they add a version to the protocol? |
| 21:59 | <bencc> | ? |
| 21:59 | <Hixie> | back when i was editing the spec, the protocol was not versioned |
| 21:59 | <bencc> | why not? |
| 21:59 | <Hixie> | because versioning on the web is even worse than user agent sniffing |
| 22:00 | <bencc> | wow. |
| 22:00 | <bencc> | this is a lost cause :) |
| 22:00 | <Hixie> | versioning is unnecessary on the web |
| 22:00 | <Hixie> | html, css, js... they all work fine without versioning |
| 22:02 | <Ms2ger> | Why did we implement the stupid version of websockets again? |
| 22:02 | <Philip`> | Version numbers are useful when you spend two years tweaking fundamental aspects of the protocol and make everyone end up implementing different revisions of the specification |
| 22:04 | <Hixie> | Philip`: yeah, don't do that :-P |
| 22:05 | <bencc> | Philip`: thank you |
| 22:05 | <Philip`> | Not everyone has enough self-control to avoid doing that :-) |
| 22:16 | <jgraham_> | I believe websokets tells you the version number in the header, doesn't it? |
| 22:17 | <bencc> | yes but the client doesn't know its version |
| 22:18 | <jgraham_> | ? |
| 22:19 | <jgraham> | Anyway ignore all versions that aren't -17 |
| 22:19 | <jgraham> | I imagine everyone will fix their implementations to the RFC soon enough |
| 22:20 | <jgraham> | (I think -17 is indicated by 13 in the version field or something stupid) |
| 22:20 | <jgraham> | (yeah it is) |
| 22:21 | <jgraham> | Anyway, I can't work out why you care about the protocol version on the client |
| 22:22 | <jgraham> | I mean obviously if you *do* care it is trivial to find out, assuming you control oth ends of the wire; just send it as part of your subprotocol e.g. in the first message |
| 22:24 | <bencc> | jgraham: but if the client doesn't support the required version, why send the first request anyway? |
| 22:24 | <bencc> | than you should use long-polling or something else instead |
| 22:25 | <jgraham> | I don't understand what situation you are worried about |
| 22:25 | <bencc> | a situation where the client has websockets but not the required version |
| 22:26 | <bencc> | how come Philip` understood me and you and Hixie don't? |
| 22:26 | <jgraham> | What case is there where you are able to establish a websocket connection, but you can't actually use that connection? |
| 22:26 | <bencc> | why should you try to establish a connection if it's won't work? |
| 22:27 | <bencc> | I forgot |
| 22:27 | <jgraham> | It seems like a reasonably good way of telling that it won't work |
| 22:27 | <bencc> | yes |
| 22:27 | <bencc> | do I have air bag in this car? |
| 22:27 | <bencc> | wait, just crash against the wall |
| 22:27 | <bencc> | no, I don't |
| 22:27 | <bencc> | are you serious? |
| 22:28 | <bencc> | are you the guys that writing the specs? |
| 22:28 | <bencc> | that's scary :) |
| 22:29 | <jgraham> | I am rally trying to be helpful here... |
| 22:29 | <jgraham> | *really |
| 22:29 | <jgraham> | What is the concrete problem you are trying to solve? |
| 22:30 | <jgraham> | Is it "I need to work with outdated versions of chrome"? |
| 22:30 | <jgraham> | (and safari, maybe? I don't know if they shipped the insecure stuff too) |
| 22:30 | <bencc> | I shouldn't try to connect with the client if the websocket on it are "broken" |
| 22:30 | <bencc> | or with an old version |
| 22:30 | <bencc> | what's complicated about it? |
| 22:30 | <jgraham> | No, that's not a problem |
| 22:31 | <bencc> | how come it's not a problem? |
| 22:31 | <jgraham> | That's a statement of something you want, but you didn't explain why you want that beyond some irrelevent metaphor about safety critical systems like airbags |
| 22:31 | <bencc> | because it's stupid to first try to use websocket and than if it fails use long-polling |
| 22:31 | <bencc> | you are wasting requests |
| 22:32 | <bencc> | and the connection takes more time |
| 22:32 | <bencc> | so the user experience your client have is bad |
| 22:32 | <bencc> | do you understand this? |
| 22:32 | <bencc> | or maybe not? |
| 22:32 | <jgraham> | Yes, but on the other hand it will also cover situations where websockets fail for some other reason e.g. due o special proxies or firewalls or wahtever |
| 22:33 | <bencc> | those are two different cases |
| 22:33 | <jgraham> | I agree that the latency could be a problem for some aplications. Is your application hihly sensitive to the initial latency? |
| 22:33 | <bencc> | not it's not |
| 22:33 | <bencc> | my users like to wait |
| 22:34 | <bencc> | it's a website for s&m so they like to suffer |
| 22:34 | <Philip`> | bencc: I wasn't trying to agree with you, I was just trying to be unhelpfully snarky about the IETF |
| 22:34 | <bencc> | ok |
| 22:34 | <jgraham> | Well with my approach you can cover them with one codepath for the short-term need (old versions of frequently updated browsers) and the long term case (intermediaries that block websockets) |
| 22:35 | <jgraham> | bencc: It is entirely non-obvious that your particular use of websockets depends on being able to establish a connection wih minimum latency |
| 22:36 | <bencc> | forget it |
| 22:36 | <bencc> | this idiotic discussion is a waste of time |
| 22:36 | <jgraham> | Consider something where the page loads and then one has to have user interaction before establishing the real conenction |
| 22:37 | <jgraham> | The time for the user to interact with the page is going to be way longer than the time to set up a connection, so you can create a trial connection during page load |
| 22:37 | <jgraham> | and then already know if it will work when the actual connection is needed |
| 22:39 | <jgraham> | OTOH if you are trying to build a search engine that pulls the results over websokets than that delay might be undesirable (although I note that you will get it in the "broken intermediary" case anyway, and that in the other case it will only persist until browsers fix their implemenations to the latest spec) |
| 22:40 | <jgraham> | (for that example I assume that the search engine tries to pull the results on page load) |
| 22:43 | <jgraham> | (oh it seems that gecko haven't updated to -17 yet but chrome has. Still I guess the server should support both) |
| 22:43 | <jgraham> | (bth -10 and -17 that is) |
| 22:43 | <jgraham> | bencc: I am sorry you think it has been a waste of time. I have really tried to help you solve your problem. I'm sorry if my suggestions didn't match the solution you had in mind. |
| 23:22 | <AryehGregor> | jgraham, I think what bencc would like is something JS-visible that says what version of WebSockets the client implements. |
| 23:22 | <AryehGregor> | So you can do if (WebSocket.version < 17) { fallback() } |
| 23:22 | <AryehGregor> | This seems reasonable when the protocol is undergoing so many iterations. |
| 23:22 | <AryehGregor> | I guess no one thought it would be this many, though. |
| 23:23 | <AryehGregor> | And we'd have to keep it around forever as a meaningless legacy constant. |
| 23:24 | <AryehGregor> | bencc, so basically I think we're just saying we're okay with annoying people in the short term because a) anything else would make the APIs or protocol more complicated in the long term, even though it will eventually serve no purpose; and b) nobody thought the protocol would take this long to stabilize, so it didn't seem necessary. |
| 23:24 | <AryehGregor> | And now, of course, we've *definitely* arrived at the final protocol version, right? |
| 23:24 | <AryehGregor> | So it's still not necessary. |
| 23:30 | <zewt> | *cough* |
| 23:33 | <bencc> | ok |