| 00:56 | <Hixie> | ok history.state is fixed |
| 00:57 | <Hixie> | ...and i guess the overall pushState/popState feature now has a new name, history.state |
| 01:49 | <Yuhong> | hsivonen: Just found this: http://msdn.microsoft.com/en-us/library/ff406036(v=VS.85).aspx |
| 02:12 | <Yuhong> | hsivonen: There is also IE9 quirks mode, defined here: http://msdn.microsoft.com/en-us/library/gg558056(v=VS.85).aspx |
| 02:14 | <AryehGregor> | Wow, there's loads of secret discussion on member-psig about the HTML5 license. |
| 02:16 | <zewt> | is "it's dangerous to go alone, take this" a sufficient license for a spec |
| 02:19 | <AryehGregor> | Doesn't sound GPL-compatible. |
| 02:19 | <zewt> | i remember when I cared about the GPL. nostalgia ... |
| 02:23 | <AryehGregor> | Oh, like half of these messages were CCd to public-html anyway. |
| 02:23 | <AryehGregor> | Still interesting, though. |
| 02:23 | <zewt> | but less so for not being secreT? :P |
| 02:24 | <zewt> | (capital T makes it even more secret) |
| 02:24 | <AryehGregor> | I mean the ones that aren't CCd to public-html are interesting. |
| 02:24 | <AryehGregor> | Although I guess I'm not allowed to say anything specific to people who don't have real membership (rather than the fake Public Invited Expert thing). |
| 02:51 | <Hixie> | AryehGregor: there's not much to report that hasn't already been reported. they spent n years coming up with a bunch of licenses none of which address all the use cases we asked for, and the MIT license does. |
| 05:46 | <micheil> | Hixie: are you about? |
| 05:46 | <Hixie> | vaguely |
| 05:49 | <micheil> | Hixie: would it be an idea to add into the websocket specification a way to enable debugging, so that you can see the actual network packets? |
| 05:49 | <Hixie> | not as part of the specification, but it would make sense for browsers to do that, sure |
| 05:49 | <micheil> | hmm, okay |
| 05:49 | <Hixie> | in firebug or whatever they call their debuggers |
| 05:49 | <micheil> | just trying to figure out whether node-websocket-server is actually following spec. |
| 05:50 | <Hixie> | the new one? |
| 05:50 | <Hixie> | new spec, that is |
| 05:50 | <micheil> | on server close, it sends 0xFF0x00, and then closes the socket |
| 05:50 | <Hixie> | i'm pretty sure that's not valid in the new spec |
| 05:51 | <micheil> | unfortunately not, I working on cutting a release that supports 75 and 76, before rewriting it all to support the latest |
| 05:51 | <Hixie> | ah ok |
| 05:51 | <micheil> | yeah. |
| 05:51 | <micheil> | to be able to support each version requires that. |
| 05:51 | <Hixie> | going to ietf was such a mistake |
| 05:51 | <micheil> | also, is there any browser support for the latest version? |
| 05:51 | <Hixie> | doubt it |
| 05:51 | <micheil> | :/ |
| 05:51 | <micheil> | makes' it hard to test then. |
| 05:51 | <Hixie> | they'll get there eventually |
| 05:52 | <micheil> | well, in all honesty, parts of their framing are better then what the original framing was |
| 05:52 | <micheil> | specifically the length based framing instead of prefix/suffix based |
| 05:53 | <micheil> | but other stuff that really belongs at userlevel has been included at protocol level |
| 06:41 | <nshaik> | Hi .. is invoking a webworker from a file:/// html and js incorrect..because i get ** Message: console message: undefined @0: SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent. |
| 07:14 | <rmccue> | Hi, quick question regarding sections and headings: are headings relative to their nearest section or the top-most one? |
| 07:14 | <rmccue> | (i.e. <section> <h1>Top</h1> <section> <h2>Another</h2> </section> </section>, or <h1> again?) |
| 09:20 | <jgraham> | micheil: Gecko have a test build of -06 |
| 09:20 | <jgraham> | Maybe WebKit also |
| 09:22 | <jgraham> | http://www.ducksong.com/misc/websockets-builds/ws-06/4.0.rc1.01/ |
| 09:24 | jgraham | gets the impression that the licesning stuff is trying to solve an impossible problem |
| 11:28 | <micheil> | jgraham: are these likely to reach end users? |
| 11:29 | <micheil> | jgraham: or are these just test builds to see that the protocol actually works? |
| 11:30 | <MikeSmith> | wow, chrome dev channel is up to v12 now |
| 11:30 | <jgraham> | Well presumably the intention is to roll the protocol out to end users eventually |
| 11:30 | <micheil> | jgraham: yeah, I'm just wondering if it'd be better to have websockets in dev only builds, or only ship up to -76, until the protocol stablises |
| 11:31 | <jgraham> | MikeSmith: Well that will happen if you increment the version number 8 times a year |
| 11:32 | <jgraham> | micheil: It would be better for no one to ship -76 |
| 11:32 | <micheil> | jgraham: well, I'm more so meaning, -76 is the latest one to have shipped, right? |
| 11:32 | <micheil> | (out of any vendor) |
| 11:32 | <jgraham> | Yeah, but only WebKit still ship |
| 11:33 | <jgraham> | And it would be nice if they would stop |
| 11:33 | <jgraham> | (off by default doesn't count) |
| 11:33 | <micheil> | so, webkit would be the only ones to maybe be implementing -06? |
| 11:33 | <jgraham> | How did you infer that? |
| 11:33 | <micheil> | okay, well, I'm more meaning, is it worth my time implementing -06? |
| 11:34 | <jgraham> | It's not like WebKit are the only people that care about WS, they're just the only people shipping the broken version |
| 11:34 | <jgraham> | micheil: No idea |
| 11:34 | <jgraham> | I guess it depends on the value of your timer |
| 11:34 | <jgraham> | *time |
| 11:35 | <micheil> | well, if it means that end users get to make use of the product, and that it isn't deprecated without any use, then, that's time well spent |
| 11:35 | <jgraham> | I have rather given up on the whole IETF thing since it became clear that there was no chance of anything I said having an effect |
| 11:35 | <micheil> | is anybody shipping any future versions of websockets yet? |
| 11:36 | <micheil> | jgraham: yeah, it does seem like a gated community in an open web. |
| 11:36 | <jgraham> | Where by "future" you mean "current"? |
| 11:36 | <micheil> | well, yeah, I guess |
| 11:36 | <jgraham> | Not afaik |
| 11:36 | <micheil> | so, nothing currently is using -06? |
| 11:37 | <jgraham> | It seems Chrome has an implementation |
| 11:37 | <jgraham> | I'm not aware that they actuallly ship it |
| 11:40 | <micheil> | hmm.. |
| 11:43 | <micheil> | jgraham: would you say this looks accurate? https://github.com/miksago/node-websocket-server/wiki/Browser-Support |
| 11:45 | <jgraham> | micheil: Opera shipped disabled by default |
| 11:45 | <micheil> | in 10.70? |
| 11:45 | <jgraham> | There is no 10.70 :) |
| 11:45 | <jgraham> | 11 |
| 11:45 | <micheil> | okay... |
| 11:46 | <micheil> | was there a 10.70? |
| 11:46 | <jgraham> | No |
| 11:46 | <jgraham> | It was called 11 |
| 11:46 | <micheil> | okay |
| 11:47 | <jgraham> | Chrome and Chromium should presumably be identical here |
| 11:47 | <micheil> | updated. |
| 11:47 | <micheil> | yeah. |
| 11:48 | <micheil> | so that should be right? (updated) |
| 11:50 | <jgraham> | I think so |
| 11:50 | <micheil> | okay, cool |
| 12:04 | hsivonen | feels sorry for Opera brand people for the toilet seat logo refusing to die in the press and on third-party sites |
| 12:27 | <MikeSmith> | hsivonen: have you gotten any new bug reports for parsing bugs since the FF4 release on the 22nd? |
| 12:31 | <hsivonen> | MikeSmith: I noticed one myself |
| 12:31 | <MikeSmith> | oh? |
| 12:31 | <hsivonen> | MikeSmith: and there's one that's tied to UA sniffing |
| 12:31 | <MikeSmith> | ok |
| 12:32 | <hsivonen> | MikeSmith: Firefox 4 doesn't reconstruct active formatting elements when it sees text in an HTML integration point |
| 12:32 | <MikeSmith> | oh |
| 12:32 | <hsivonen> | MikeSmith: I gave up on debugging the UA sniffing case after observing that it worked if I faked Chrome's UA string |
| 12:32 | <MikeSmith> | hmm |
| 12:34 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=644144 |
| 12:34 | <MikeSmith> | about the former bug, are there sites for which that has caused significant problems? |
| 12:34 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=643410 |
| 12:35 | <hsivonen> | MikeSmith: none known. I noticed it when I reviewed a spec change |
| 12:35 | <MikeSmith> | ok |
| 12:35 | MikeSmith | looks at the bug reports |
| 12:35 | <hsivonen> | see also http://www.w3.org/Bugs/Public/show_bug.cgi?id=12357 |
| 12:36 | MikeSmith | looks |
| 12:36 | <hsivonen> | oh, and also https://bugzilla.mozilla.org/show_bug.cgi?id=644034 |
| 12:36 | <MikeSmith> | that seems like an oversight |
| 12:37 | <MikeSmith> | oh |
| 12:37 | <MikeSmith> | that's not good |
| 12:37 | <MikeSmith> | whoah |
| 12:37 | <MikeSmith> | but you're WONTFIXing it? |
| 12:37 | <hsivonen> | MikeSmith: well, didn't break sites in the wild, so OK |
| 12:37 | <MikeSmith> | ah, OK |
| 12:38 | <hsivonen> | MikeSmith: Firefox 4 complies with the spec, spec makes sense, no sites in the wild broken |
| 12:38 | <hsivonen> | one broken bank so far: https://bugzilla.mozilla.org/show_bug.cgi?id=643710 |
| 12:40 | <MikeSmith> | developers of bank sites as a class seem to be in constant competition with airline sites to prove who can come up with the most bizarre asshattedly broken code |
| 12:40 | <hsivonen> | MikeSmith: we unbroke united.com before shipping |
| 12:41 | <MikeSmith> | thanks |
| 12:41 | <MikeSmith> | as a United customer I appreciate it :) |
| 12:42 | <hsivonen> | MikeSmith: but you are a U.S. citizen, right? the bug affected only non-U.S. citizens |
| 12:42 | <MikeSmith> | ah, OK |
| 12:42 | <karlcow> | :D |
| 12:43 | <MikeSmith> | hsivonen: so what's the current target date for FF5? |
| 12:44 | MikeSmith | notices his Minefield is now at 4.2 |
| 12:45 | <hsivonen> | I really wish we'd fix the prerelease UA strings to say what the stable version will say |
| 12:46 | <hsivonen> | MikeSmith: I can't find the date written anywhere, so I'll refrain from repeating hearsay from memory |
| 12:49 | <karlcow> | I wonder if the quick evolution of version numbers will help killing the user agent sniffing based on version numbers |
| 12:49 | <wilhelm> | That would be nice. |
| 12:49 | <hsivonen> | that would be an excellent outcome, yes |
| 12:50 | <Rik`> | MikeSmith: June 22 I think |
| 12:50 | <hsivonen> | though the problems I see are more often based on browser name than number |
| 12:51 | <hsivonen> | like sites not working, because Firefox 4 doesn't have the substring "Safari" in the UA string |
| 12:51 | <hsivonen> | that's the most common one I've seen |
| 12:53 | <hsivonen> | karlcow: btw, you might want to add wikia.com to the list of sites you will need to evangelize when Opera implements HTML5-compliant script execution. https://bugzilla.mozilla.org/show_bug.cgi?id=610369 |
| 12:55 | <karlcow> | hsivonen: thanks. Useful I already see a few bugs opened for wikia |
| 12:59 | <MikeSmith> | Rik`: thanks |
| 13:13 | <karlcow> | > Drieu left Apple in March 2010, where he was the head of the company's rich media and applications group. After a five month period without employment, he joined Motorola. His work with Web standards groups WhatWG and W3C and his Web-related patents suggest that he would be well-suited to lead an operating system development effort. |
| 13:13 | <karlcow> | — http://www.informationweek.com/news/development/mobility/showArticle.jhtml?articleID=229400097 |
| 13:21 | <MikeSmith> | karlcow: huh? |
| 13:22 | <MikeSmith> | http://www.linkedin.com/in/gillesdrieu |
| 13:23 | <MikeSmith> | look in the Patents and Publications part |
| 13:23 | <MikeSmith> | wtf |
| 13:24 | <miketaylr> | O_o |
| 13:24 | <MikeSmith> | "Participated very actively to the Khronos WebGL working group (spec editor)." |
| 13:25 | <MikeSmith> | hey, maybe he's actually Chris Marrin |
| 13:25 | <MikeSmith> | under an assumed name |
| 13:26 | <karlcow> | I have no idea where they got the name. The article is thin. |
| 13:29 | <karlcow> | impressive list of contributions |
| 13:34 | <karlcow> | hmm http://www.google.com/search?q=css+drieu++site%3Aw3.org |
| 13:35 | <karlcow> | http://www.w3.org/Search/Mail/Public/search?keywords=drieu |
| 13:36 | <MikeSmith> | well, you can't blame a man for padding his resume a bit |
| 13:36 | <MikeSmith> | god knows I have |
| 13:36 | <MikeSmith> | http://www.linkedin.com/in/sideshowbarker |
| 13:37 | <karlcow> | heh |
| 15:06 | <jgraham> | Is http://hoppipolla.co.uk/tests/navigation/001.html making some unreasonable assumption, or is the stuff in the spec about fragment navigation being async not really true? |
| 15:06 | <jgraham> | (disclaimer: I didn't write that test) |
| 15:10 | <aho> | awful indention |
| 15:10 | <jgraham> | Oh, that is my fault |
| 15:10 | <jgraham> | It lost all the whitespace when I copied it into emacs and I made a half-assed attempt at reindenting it |
| 15:10 | <aho> | i wont bother trying to understand what it does, if it looks like this :> |
| 15:13 | <aho> | or more accurately: if i'd try to read it i'd probably get an aneurysm in the process |
| 15:14 | <jgraham> | It could be better now |
| 15:17 | <aho> | i'd say you cant actually test this behavior with js correctly |
| 15:19 | <aho> | hash is a magic host object... if i set it to some other value it can either do that stuff synchronously or asynchronously... however, reading that value back won't necessarily tell me if it's done with doing so or not |
| 15:19 | <jgraham> | aho: My reading of the spec is that the value of location.hash is given by the current document address |
| 15:20 | <jgraham> | The current document address doesn't change until the navigation occurs |
| 15:20 | <aho> | e.g. it might cache that new value and don't even bother with crossing the native bridge if that value is requested |
| 15:20 | <jgraham> | and the navigation is async |
| 15:21 | <jgraham> | aho: Are you basing this on the spec or on the behaviour of some browser(s) or on something else? |
| 15:22 | <aho> | is this specified in depth? |
| 15:22 | <jgraham> | Yes |
| 15:22 | <aho> | linky? |
| 15:24 | <jgraham> | http://www.whatwg.org/specs/web-apps/current-work/#location and references therein |
| 15:24 | <jgraham> | In particular http://www.whatwg.org/specs/web-apps/current-work/#navigate |
| 15:24 | <jgraham> | and http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid |
| 15:25 | <bfrohs> | http://twitter.com/WHATWG/status/51084738148057088 - Might want to look into tweaking the automatic shortener. Perhaps shorten to last full word? (hacks.mozilla link broken in tweet) |
| 15:28 | <aho> | http://www.whatwg.org/specs/web-apps/current-work/#navigate <- about navigating across documents, does not apply |
| 15:28 | <aho> | http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid <- doesn't mention anything async |
| 15:29 | <jgraham> | aho: The first one is the definition of "Navigate" |
| 15:29 | <jgraham> | and the second one says "queue a task" |
| 15:35 | <aho> | well, imo this is like retrieving css values. you set some new value(s) (which might be cached/delayed), but once you try to retieve them you'll always get those new values back, because those changes were flushed forcefully |
| 15:36 | <aho> | so from the js side it always looks synchronous (but it isn't necessarily synchronous) |
| 15:37 | <aho> | (would be a lot more complicated to handle if this weren't the case) |
| 15:39 | <jgraham> | aho: If that is the intended model, then either I am misreading the spec, or the spec is wrong |
| 15:40 | <jgraham> | Which brings me back to the original question :) |
| 15:42 | <aho> | well... either way... you can't really test it with js unless the spec explicitly states that reading the hash must be a live value and must not cause any kind of flushing, which would be a) annoying to use and b) annoying to implement :> |
| 15:43 | <aho> | (i'm aware that this still doesn't really answer your question, but it's the best shot i got) |
| 15:43 | <jgraham> | The whole point is that the javascript-visible behaviour has to be specified |
| 18:34 | <AryehGregor> | So there's no way to get the Selection in IE9 to contain an arbitrary range except addRange(), since it doesn't support extend() . . . but addRange() fails unpredictably with "Error: Unspecified error." |
| 18:34 | <AryehGregor> | Okay, I'm going to have to bite the bullet and look into IE's proprietary selection APIs. |
| 18:38 | <AryehGregor> | Except I forgot that there seems to be no actual way to set a TextRange to a given element/offset. |
| 18:38 | <AryehGregor> | SIGH. |
| 18:41 | AryehGregor | tries upgrading to IE9 final |
| 19:01 | <bga_> | js everywhere :) http://git.gnome.org/browse/gnome-shell/tree/js/ui |
| 19:10 | <AryehGregor> | Do any Opera people know what would cause Selection.addRange() to silently fail in some cases? |
| 19:13 | <gsnedders> | AryehGregor: In Opera? |
| 19:13 | <AryehGregor> | gsnedders, well, I'd hardly Opera people about other browsers, would I? |
| 19:13 | <AryehGregor> | Specifically in: http://aryeh.name/spec/dom-range/test/Selection-extend.html |
| 19:15 | <AryehGregor> | (which takes a long time to load, BTW) |
| 19:15 | <AryehGregor> | Notice how it complains rangeCount is 0 in every single case. |
| 19:19 | AryehGregor | prepares a slightly more minimal test-case |
| 19:21 | <AryehGregor> | . . . Does addRange() work at all in Opera? |
| 19:22 | <AryehGregor> | data:text/html,<!doctype html><script>getSelection().addRange(document.createRange()); alert(getSelection().rangeCount);</script> |
| 19:23 | <AryehGregor> | Actually, do any Selection mutation methods work at all? |
| 19:25 | <AryehGregor> | rangeCount works fine if you create the selection yourself. |
| 19:25 | <AryehGregor> | Hmm, wait, how do my execCommand tests work in Opera? |
| 19:25 | AryehGregor | looks |
| 19:25 | <AryehGregor> | That uses addRange() . . . |
| 19:26 | <AryehGregor> | data:text/html,<!doctype html><script>getSelection().addRange(document.createRange()); alert(typeof getSelection().getRangeAt(0));</script> |
| 19:26 | <AryehGregor> | Oh, it's just rangeCount that's totally broken. |
| 19:26 | <AryehGregor> | It doesn't work for programmatically-set ranges. |
| 19:26 | <AryehGregor> | That explains it. |
| 19:28 | <AryehGregor> | No, wait. |
| 19:28 | <AryehGregor> | Hmm. |
| 19:30 | <AryehGregor> | Okay, so getRangeAt(0) works in Opera even if there are no ranges. |
| 19:32 | <AryehGregor> | Oh, I see. |
| 19:32 | <AryehGregor> | Opera won't allow you to add just any range. |
| 19:33 | <AryehGregor> | Maybe it has some visibility requirement like WebKit does. Hmm. |
| 19:33 | <AryehGregor> | rangeCount does seem to work. |
| 19:36 | <AryehGregor> | So adding a collapsed range seems not to work, and maybe also an invisible range. |
| 19:42 | <AryehGregor> | Aha, finally. |
| 19:42 | <AryehGregor> | The stuff I was selecting was below the test log, and didn't get displayed for some reason. |
| 19:45 | <AryehGregor> | Now Opera passes 80 tests, instead of 1! |
| 19:46 | <AryehGregor> | That's 80 out of 10913, but hey, at least all the failures are legitimate now. |
| 19:48 | <AryehGregor> | Also, it now runs the tests incredibly fast, presumably because >99% are now no-ops (don't even try to run extend()). |
| 19:49 | <Hixie> | i need to stop getting spam from people offering me canvas ink |
| 19:49 | <Hixie> | as funny as it is |
| 19:49 | <AryehGregor> | That is pretty funny. |
| 19:55 | <Hixie> | jeez, even with the big red warning on the TR/ page i _still_ get people e-mailing me questions about it without checking the latest draft first |
| 19:58 | <AryehGregor> | Hmm, still getting "Error: Unspecified error" in IE9 final. I totally wasn't getting this yesterday. |
| 19:58 | <Ms2ger> | Hixie, I'd argue this is sadder: |
| 19:58 | <Ms2ger> | isFirefox: (document.ATTRIBUTE_NODE != null && window.directories != null), |
| 19:59 | <Hixie> | sadder than what? |
| 19:59 | <Ms2ger> | TR/ |
| 19:59 | <othermaciej> | what's "canvas ink"? |
| 20:00 | <Hixie> | othermaciej: ink. for paintings and stuff. |
| 20:05 | <AryehGregor> | Oh, phew, figured it out. |
| 20:46 | <AryehGregor> | Does anyone know where I can find version history for <http://dev.w3.org/csswg/css3-text/>;? |
| 20:53 | <Ms2ger> | http://dev.w3.org/cvsweb/csswg/css3-text/ |
| 20:53 | <AryehGregor> | Great, thanks. |
| 21:48 | <AryehGregor> | Hah, <sup> and <sub> don't use CSS even with styleWithCSS true. |
| 21:49 | <AryehGregor> | Fits my theory of the origins of styleWithCSS perfectly. |
| 21:49 | <AryehGregor> | In Gecko, anyway. |
| 21:50 | <AryehGregor> | In WebKit it does <span style="vertical-align: ...">, which is wrong because it doesn't reduce the size. |
| 22:20 | <kennyluck> | Which browser outputs <strong> and <em> for content editing? IE? So sad. |
| 22:21 | <AryehGregor> | IE and Opera. |
| 22:21 | <AryehGregor> | At least their more recent versions. |
| 22:21 | <AryehGregor> | It's possible this was motivated by the deprecation of <b> and <i> in some earlier HTML versions. Not sure, it would help if I know when they started. |
| 22:22 | <AryehGregor> | I think IE originally might have output <b> and <i>. Anyone have IE4 to test in? :) |
| 22:22 | <AryehGregor> | (not that I'd have any idea how to write a test for IE4 even if I did have a copy handy) |
| 22:23 | <AryehGregor> | There are non-browser-based WYSIWYG editors that output <strong> and <em> for bold and italics, too. |
| 22:23 | <kennyluck> | <b> and <i> were never deprecated last time I checked HTML4. |
| 22:23 | <AryehGregor> | I've seen it. |
| 22:23 | <AryehGregor> | Hmm, right, but were they removed from XHTML 2 or something? |
| 22:23 | <AryehGregor> | I can't remember all these ridiculous obsolete decisions. |
| 22:24 | <kennyluck> | Yeah, I saw a BBC guideline for their site which says no <i> <b> <u> is allowed. |
| 22:24 | <AryehGregor> | http://www.w3.org/TR/xhtml2/mod-text.html#s_textmodule |
| 22:24 | <AryehGregor> | Don't you love the ™ in the titles of the XHTML 1.1 and 2.0 specs? |
| 22:24 | <AryehGregor> | So classy. |
| 22:25 | <othermaciej> | they trademarked "XHTML" to try to prevent forking |
| 22:25 | <kennyluck> | Don't know what that means |
| 22:25 | <AryehGregor> | Don't know what what means? |
| 22:25 | <kennyluck> | Oh. |
| 22:26 | <AryehGregor> | Why couldn't try trademark HTML also? They invented that too, or at least TBL did. |
| 22:26 | <kennyluck> | I can't believe XHTML was trademarked. I actually didn't think what ™ is there for. |
| 22:26 | <AryehGregor> | Why couldn't they trademark HTML also? They invented that too, or at least TBL did. |
| 22:27 | <AryehGregor> | http://www.trademarkia.com/xhtml-75636639.html |
| 22:27 | <AryehGregor> | It seems to be registered to some dude in California? |
| 22:27 | <AryehGregor> | Or possibly Norway. |
| 22:28 | <AryehGregor> | Looks like CERN trademarked HTML at one point: http://www.trademarkia.com/html-74719487.html |
| 22:28 | <Hixie> | they tried trademarking html, but they couldn't keep it for some reason or something |
| 22:29 | <othermaciej> | HTML was considered a generic term by then |
| 22:29 | <Hixie> | (that was one reason i called the spec "Web Applications 1.0" way back when) |
| 22:29 | <othermaciej> | or something |
| 22:30 | <AryehGregor> | Why would they care about forks, honestly? If the browsers are forking, they're not going to keep them by suing them, and if anyone else is forking, they can just be ignored. |
| 22:30 | <AryehGregor> | Idiocy. |
| 22:30 | <Hixie> | beats me |
| 22:30 | <Hixie> | what's worse is that none of their attempts to stop forking have worked |
| 22:31 | <Hixie> | both ISO and WHATWG (opposite ends of the spectrum, really) have forked HTML successfully despite their best attempts at stopping it |
| 22:31 | <zewt> | solution to forking: make something good enough that people don't need to fork it |
| 22:31 | <Hixie> | yes! |
| 22:31 | <Hixie> | that's what i keep saying |
| 22:31 | <Hixie> | their continued fear imho is fear that they can't make something good enough |
| 22:32 | <Hixie> | in other news: people keep telling me UDP packets above the MTU will fail to transmit. Is that true? I thought they'd just get fragmented at the IP level, but would still make it through eventually, am I wrong? |
| 22:32 | <zewt> | heh you know |
| 22:32 | <zewt> | despite all the networking I've done I don't know the answer to that question |
| 22:32 | <zewt> | i'd expect the same thing, yet my intuition is also that it won't work |
| 22:33 | <AryehGregor> | Hixie, the people actually making the standards seem to not mind forking so much. It's the Advisory Committee that voted down forking, right? |
| 22:33 | <Hixie> | realistically it's w3c staff and the paying members, yes |
| 22:33 | <zewt> | fear that someone will fork and no longer take their committee under advisement? heh |
| 22:33 | <Hixie> | (not all of either, but a plurality) |
| 22:33 | <AryehGregor> | Members pay a decent amount of money for the privilege of having a say in all these standards. Unsurprising that they want to protect their investment. |
| 22:34 | <AryehGregor> | Likewise, W3C staff can be expected to want to protect their job and the work they've invested. |
| 22:34 | <AryehGregor> | I wouldn't call it fear. |
| 22:35 | <Hixie> | if they were confident they could make something good enough, they would not think of allowing forking as a risk to their investment |
| 22:35 | <AryehGregor> | But the people making the decision aren't the ones actually making the specs. They have no control over spec quality. |
| 22:35 | <AryehGregor> | At best they have some indirect influence. |
| 22:35 | <Philip`> | If UDP fragmentation does work reliably, it still seems bad from the perspective of reliability, since dropping a single fragment will cause the whole message to be lost |
| 22:36 | <Philip`> | so the effect of random packet loss will be amplified significantly |
| 22:36 | <AryehGregor> | Fragmentation on the IP level certainly won't work in IPv6, right? |
| 22:36 | Philip` | has no idea whether it does work reliably in practice or if some/many routers are stupid and just drop packets, though |
| 22:36 | <Hixie> | AryehGregor: whether they influence it or not, the point is that they wouldn't fear for their investment if they were confidents the w3c's specs were good. |
| 22:36 | <Hixie> | Philip`: that's what i thought too |
| 22:36 | <AryehGregor> | And in IPv4 you want to avoid it because it's typically a big waste of resources, unless your packet size happens to be equal to or slightly under a multiple of the MTU. |
| 22:37 | <Hixie> | Philip`: but people seem to say it's worse than just less reliable |
| 22:37 | <AryehGregor> | Hixie, sure. |
| 22:37 | <AryehGregor> | Hixie, are you considering IPv6 here? |
| 22:37 | <Hixie> | both |
| 22:37 | <AryehGregor> | Oh, wait, I forgot. |
| 22:37 | <zewt> | well, many protocols don't have variable-size packets--you're more likely to depend on IP fragmentation if, for example, you have 1000-byte packets, which fit in most MTUs but not all |
| 22:37 | <AryehGregor> | IPv6 also transparently fragments packets, just it requires the sender to do it instead of the router, right? |
| 22:38 | <zewt> | that is, I think most of the time if you're expecting fragmentation to work, it's not for the normal case, but to work around the edge cases |
| 22:39 | <AryehGregor> | So speaking of MTUs, when are we going to get rid of Ethernet requirements that have been obsolete for decades and allow reasonable MTUs like 64 KB? :) |
| 22:40 | <Philip`> | Message 3 on http://www.groupsrv.com/groups/view.php?c=computer&g=1804&id=42288&p=0 suggests some firewalls with stateful packet inspection drop fragmented packets (because they're too expensive to reconstruct) |
| 22:43 | <zewt> | FWIW: running netcat -u on a remote server, and nc -u < test.txt to it, it looks like packets larger than the MTU are not received |
| 22:43 | <zewt> | (set my MTU to 700 and tried sending a 900-byte packet a few times, never received; raised it back to 1500 and it works) |