| 00:00 | <Hixie> | Philip`: did you test <script src> ? yahoo seems to follow that |
| 00:01 | <Philip`> | Hixie: Yes |
| 00:01 | <Philip`> | I might just need to be more patient and give the crawlers more time |
| 00:01 | <Philip`> | or maybe they get suspicious that my test page is linking to 404s and stop following all the other links |
| 00:02 | <Hixie> | heh |
| 01:35 | <Hixie> | i wonder how i can determine if my apache is using mpm_prefork_module or mpm_worker_module |
| 01:37 | <Philip`> | Hixie: Look at http://whatever/server-info if you have mod_info |
| 01:38 | <Hixie> | it appears i don't |
| 01:38 | <Hixie> | i have something called "Apache Server Status" |
| 01:39 | <Philip`> | (I guess it also needs to be configured somehow, and appropriate permissions set, and everything, which is probably not entirely trivial) |
| 01:39 | <Hixie> | i think i must be using prefork |
| 01:40 | <Philip`> | You could count the number of processes, since mpm_worker_module only has one |
| 01:40 | <Philip`> | Oh, no it doesn't |
| 01:40 | Philip` | shouldn't trust the first web page he reads |
| 01:40 | <Hixie> | no, it can have many |
| 02:26 | <mcarter> | hello |
| 02:26 | <mcarter> | Hixie, i sent in that feedback |
| 02:27 | <Hixie> | sweet |
| 02:27 | <Hixie> | thanks! |
| 02:27 | <Hixie> | i'll probably do the tcp stuff right after the url stuff i'm doing now |
| 02:27 | <Hixie> | (which is turning into a giant pile of annoyance) |
| 02:28 | <mcarter> | which url stuff is that? (link?) |
| 02:28 | <Hixie> | search for "URLs" in the spec |
| 02:33 | <Hixie> | does anyone do TLS upgrade on normal HTTP today? |
| 02:35 | <Hixie> | other than that i generally agree with what you're proposing |
| 02:35 | <othermaciej> | mcarter: I like your proposal |
| 02:36 | <othermaciej> | mcarter: my only further comment is that maybe it should be called something other than TCPConnection now |
| 02:36 | <othermaciej> | since it is so far from a generic TCP connection |
| 02:36 | <mcarter> | yeah, thats a good point |
| 02:36 | <othermaciej> | maybe the protocol should get a real name (instead of being called "TCPConnection"), and then if that is Foo, the API can be FooConnection |
| 02:37 | <Hixie> | yeah the name needs to change |
| 02:37 | <othermaciej> | (clearly Foo cannot be "TCP" because that is already taken as a protocol name) |
| 02:37 | <othermaciej> | you could also imagine a name that is about the interestingly different functionality |
| 02:37 | <othermaciej> | DuplexConnection, TwoWayChannel, something like that |
| 02:38 | <Hixie> | yup |
| 02:38 | <othermaciej> | I am kind of excited |
| 02:38 | <Hixie> | i want the server to return the Host value (or maybe the URL value, even) |
| 02:38 | <Hixie> | in the initial handshake response |
| 02:39 | <Hixie> | so that naive implementations on the server side aren't trivially usable cross-site |
| 02:39 | <othermaciej> | this is the first thing I have seen that seems like a viable two-way messaging solution in the browser |
| 02:39 | <Hixie> | thought maybe Access-Control is enough? |
| 02:39 | <Hixie> | Access-Control seems really heavyweight for this |
| 02:39 | <othermaciej> | yeah, you could use Access-Control for cross-site |
| 02:40 | <othermaciej> | it only takes one header for an A-C response to allow access, doesn't it? |
| 02:40 | <Hixie> | yeah but ac has lots of other overhead, potentially |
| 02:41 | <Hixie> | ac is really for HTTP, not for this protocol |
| 02:41 | <othermaciej> | what does AC have that would add overhead and not be beneficial for this protocol? |
| 02:42 | <Hixie> | i dunno, i don't know what AC has, it's in such flux :-) |
| 02:42 | <Hixie> | but e.g. the method and header whitelisting |
| 02:42 | <othermaciej> | I don't know what it has either, but I am trying to learn |
| 02:42 | <mcarter> | well, i figured it was better to point at something in flux rather than invent a new solution to the same problem |
| 02:42 | <othermaciej> | method whitelisting wouldn't be needed since the method is GET |
| 02:43 | <Hixie> | the fact that it's a two-step preflight/flight mechanism rather than just an upgrade |
| 02:43 | <othermaciej> | header whitelisting shouldn't be needed unless it is important for this API to allow custom headers |
| 02:44 | <othermaciej> | oh, I guess the method is OPTIONS, not GET, in mcarter's protocol |
| 02:44 | <mcarter> | othermaciej, the method i proposed was OPTIONS |
| 02:44 | <mcarter> | right |
| 02:45 | <mcarter> | it doesn't make sense to return any resource so GET didn't really make sense. OPTIONS seems like the right fit. But you're still right -- we don't need method whitelisting |
| 02:45 | <othermaciej> | perhaps AC should take this into consideration as a potential use case, unless we think this case can be handled with a simpler mechanism that can't be applied to AC's other use cases |
| 02:45 | <Hixie> | basically it seems to me like using Access-Control here is like using XLink for svg's <style xlink:href=""> mechanism |
| 02:46 | <Lachy> | http://www.sproutcore.com/2008/05/28/understanding-the-ie-dom/ |
| 02:46 | <Hixie> | a theoretical fit that's not really reusing the actual semantics, just the syntax |
| 02:46 | <mcarter> | I'm a bit lost. What are the semantics vs. syntax of AC? |
| 02:46 | <othermaciej> | don't we actually want cross-site access-control semantics? |
| 02:47 | <othermaciej> | i.e. deny cross-site by default, give server full info, let either server or client deny, limit to certain sites, etc |
| 02:47 | <othermaciej> | is there a reason that's not good for TCPConnection? |
| 02:48 | <othermaciej> | and if so, what would be the simpler model that would work? |
| 02:48 | <othermaciej> | (these are not just rhetorical questions, I don't actually know the answer to the last two there) |
| 02:49 | <mcarter> | I think we actually want cross-site access-control semantics |
| 02:50 | <mcarter> | and I think AC is a fine fit for TCPConnection |
| 02:50 | <mcarter> | but on the other hand, I don't understand the objection |
| 02:50 | <Hixie> | Lachy: interesting |
| 02:51 | <Hixie> | mcarter: the semantics are all the algorithms in the AC spec, like the cache, doing the preflight, etc |
| 02:51 | <Hixie> | othermaciej: we want cross-site access-control semantics just like SVG wanted linking semantics |
| 02:51 | <othermaciej> | Lachy: I don't understand the distinction he is making between "peer objects" and "wrappers" |
| 02:51 | <Hixie> | othermaciej: but AC is not just "cross-site access-control semantics", it's also "how to respond to an HTTP redirect", etc |
| 02:51 | <othermaciej> | WebKit's JavaScript DOM bindings are wrappers around the core DOM that call through |
| 02:52 | <Hixie> | othermaciej: the simpler model would be just to ask the server to include a "header" in its response consisting of the reconstructed URL, and having the client abort of that header is absent or not exactly the expected value |
| 02:52 | <othermaciej> | Hixie: what reconstructed URL? |
| 02:53 | <othermaciej> | the target URL or the referer? |
| 02:53 | <othermaciej> | it can't necessarily reconstruct the referer since that is often blocked |
| 02:53 | <Hixie> | target |
| 02:53 | <Hixie> | but i'm on crack |
| 02:53 | <othermaciej> | reconstructing the target URL doesn't provide cross-site access control |
| 02:53 | <Hixie> | and should be talking about the referer |
| 02:54 | <othermaciej> | or better yet, Access-Control-Origin |
| 02:54 | <othermaciej> | and it could return an Access-Control header |
| 02:54 | <Hixie> | yeah |
| 02:54 | <Hixie> | i don't understand how we would use Access-Control (other than its syntax) |
| 02:54 | <Hixie> | e.g. the correct response to an HTTP redirect here should be to bail |
| 02:54 | <Hixie> | not to follow the redirect and apply Access-Control semantics |
| 02:54 | <mcarter> | we may want to specify a way of dealing with redirects with TCPConnection |
| 02:55 | <othermaciej> | yeah, I think you may want to specify that this API doesn't follow redirects |
| 02:55 | <othermaciej> | (then Access-Control rules for how to follow a redirect don't apply) |
| 02:56 | <mcarter> | if we're using URIs then it seems reasonable for the server to send back a 301 and expect the client to follow it |
| 02:56 | <Hixie> | yeah but then it's not really access-control |
| 02:56 | <Hixie> | i mean, look at the spec: http://dev.w3.org/2006/waf/access-control/#processing-model |
| 02:56 | <Hixie> | we don't need 90% of that |
| 02:56 | <othermaciej> | I just realized, I don't remember whether the correct spelling is "referer" or "referrer" any more |
| 02:56 | <othermaciej> | damn you, interweb |
| 02:56 | <Hixie> | reusing the syntax isn't gaining us anything except confusion imho |
| 02:56 | <othermaciej> | well we could make a different syntax but you'd basically want it to do what Access-Control-Origin and Access-Control do |
| 02:56 | <othermaciej> | IMO |
| 02:56 | <mcarter> | hmm, that spec blacklists the Upgrade header |
| 02:57 | <othermaciej> | even if spelled differnetly |
| 02:57 | <othermaciej> | mcarter: the client of access control (for instance the XHR caller) can't set it |
| 02:57 | <othermaciej> | that doesn't mean an implementation of a protocol using A-C can't send it |
| 02:57 | <Hixie> | also we have to assume that the server isn't checking, e.g. Host, and thus that the client will have to do all the security, imho |
| 02:57 | <Hixie> | which means doing this even for same-site requests |
| 02:57 | <mcarter> | othermaciej, i see |
| 02:58 | <othermaciej> | Hixie: why would you need it for same-site requests? DNS rebinding (that applies to data available w/o credentials but still somehow restricted but not checking the Host header)? |
| 02:59 | <Hixie> | shared hosting providers |
| 03:00 | <othermaciej> | I guess we could try to make the server prove it checked Host (by echoing it back or something) |
| 03:00 | <Hixie> | that's the idea, right |
| 03:00 | <othermaciej> | what's the threat model with shared hosting providers? |
| 03:01 | <Hixie> | so then people will either explicitly opt in by just echoing it, or always echo back the expected value without checking it |
| 03:01 | <othermaciej> | let's say evil.com and victim.com share a physical server, different virtual servers |
| 03:01 | <Hixie> | evil.com:80 opens a DuplexConection to evil.com:81, which is actually run by victim.com |
| 03:01 | <othermaciej> | who has the TCPConnection resource up? |
| 03:01 | <othermaciej> | that would be subject to Access-Control, would it not? |
| 03:02 | <othermaciej> | since it is a different port |
| 03:02 | <Hixie> | yeah i guess so |
| 03:02 | <Lachy> | othermaciej, I'm not entirely sure either. But AFAICT, it seems to be that the peer objects are real JS objects somehow linked with the internal C++ objects, whereas the wrappers are just exposing JS APIs on C++ objects. |
| 03:02 | <Hixie> | i suppose we could use Access-Control, i'm just really weary of poisining Access-Control the way XLink was poisoned |
| 03:03 | <Hixie> | mcarter: thanks again for the feedback, it's great stuff |
| 03:03 | <othermaciej> | Hixie: I'm not 100% sure it will work, then again, I am also not 100% sure what is even in access-control at this point |
| 03:03 | <Hixie> | yeah |
| 03:03 | <othermaciej> | but studying access-control is on my near-term agenda |
| 03:03 | <othermaciej> | I will keep this in mind as a potential use case |
| 03:03 | <mcarter> | Hixie, yeah, glad to be a part of this discussion. sorry it took so long. |
| 03:03 | <Hixie> | mcarter: np |
| 03:04 | <Hixie> | right i'm gonna go get food |
| 03:04 | <Hixie> | and work on URLs more later |
| 03:04 | <Hixie> | this URLs work is really boring me to death |
| 03:04 | <Hixie> | as you can tell by the lack of significant progress on my chart :-) |
| 03:04 | <Hixie> | bbl |
| 03:04 | <othermaciej> | later! |
| 03:05 | <othermaciej> | mcarter: I agree, your proposal looks very good |
| 03:06 | <othermaciej> | Lachy: I know a lot about how WebKit's DOM bindings work, and if what we do is *not* wrapping, then I don't know what is |
| 03:06 | <mcarter> | I'm getting ready to release Orbited 0.5 which has a preliminary implementation of TCPConnection |
| 03:07 | <mcarter> | maybe I should start calling it DuplexConnection now |
| 03:07 | <Lachy> | there was a footnote at the end of the article that basically pointed out the peer model was a simplified version of what webkit and firefox really do. |
| 03:07 | <mcarter> | so there's no confusion |
| 03:08 | <othermaciej> | I think the difference is more of how hard the wrappers try to look like real JS objects and not leak implementation details, than of fundamental architecture difference |
| 03:09 | <Lachy> | yeah, maybe. |
| 03:10 | <Lachy> | I'm interested to see how sproutcore implemented their peer model. I wonder if they actually create a new object for every element in the DOM, as the diagram seems to suggest. |
| 03:10 | <Lachy> | that would seem quite inefficient though. |
| 03:10 | <othermaciej> | I'd expect is is more likely that their view abstraction is like the "widget" abstraction in many other JS libraries |
| 03:11 | <othermaciej> | that it may be a composite of multiple elements |
| 03:13 | <Lachy> | othermaciej, there are articles suggesting that sproutcore was created by Apple for MobileMe, but I can't see anywhere on sproutcore.com that says they're affiliated with Apple at all. Do you know if it was, or if was created by others and Apple is just using it? |
| 03:14 | <othermaciej> | Lachy: the main SproutCore guy works for Apple on MobileMe, and MobileMe uses it |
| 03:14 | <othermaciej> | I don't know offhand if he created it before working for Apple or after |
| 03:14 | <othermaciej> | or who else uses it |
| 03:14 | <Lachy> | ah, ok. |
| 03:14 | <othermaciej> | or any other details |
| 03:15 | <Lachy> | it seems to be a fiarly recent creation, since it looks like sproutcore.com was only launched in May |
| 03:17 | <othermaciej> | I gotta head out |
| 03:17 | <othermaciej> | later |
| 04:59 | <takkaria> | anyone around familiar with the html5lib tests? |
| 05:02 | <takkaria> | just there are some tests which seem to ensure that CRs turn into LFs and I can't see anywhere where that's actually specced |
| 05:36 | <Hixie> | is there a version of http://muffin.doit.org/docs/rfc/tunneling_ssl.html that is more official? |
| 07:32 | <hsivonen> | takkaria: http://www.whatwg.org/specs/web-apps/current-work/#preprocessing |
| 07:36 | <Hixie> | mcarter: yt? |
| 07:36 | <Hixie> | mcarter: in the proxy case, what does the handshake look like for proxy <-> server? |
| 07:38 | <mcarter> | hey |
| 07:41 | <mcarter> | well, the proxy will forward all the bytes through exactly, AFTER the HTTP Connect request |
| 07:41 | <mcarter> | so the handshake ends up looking identical from the end-server's view |
| 07:44 | <mcarter> | actually, that explanation wasn't clear, and i think there is an oversight in my proposal |
| 07:44 | <Hixie> | the proxy doesn't say CONNECT to the server? |
| 07:44 | <mcarter> | no |
| 07:45 | <Hixie> | is this documented anywhere? i couldn't find any RFCs about it. |
| 07:45 | <mcarter> | 1) client says HTTP CONNECt...\r\n\r\n to the proxy |
| 07:45 | <mcarter> | 2) proxy sends back HTTP/1.x 200 OK...\r\n\r\n to the client |
| 07:45 | <mcarter> | 3) proxy tunnels all bytes in both directions |
| 07:45 | <mcarter> | yeah, refer to http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt at the bottom of page 4 |
| 07:46 | <Hixie> | that's just a draft |
| 07:46 | <Hixie> | there's gotta be a real spec for this surely |
| 07:47 | <mcarter> | hmm, maybe. I'm pretty certain that actual implementations work as specified by that draft, at least the simple example they have on page 4 |
| 07:50 | <Hixie> | no part of that draft seem to mention actually connecting to the final server :-) |
| 07:53 | <mcarter> | yeah, they never specifically say "and then the proxy connects to the server" |
| 07:53 | <mcarter> | but they do imply it in a number of places |
| 07:54 | <Hixie> | yeah |
| 07:54 | <Hixie> | this seems seriously underspecified |
| 07:54 | <Hixie> | i'm starting to understand why proxies suck so much |
| 07:56 | <mcarter> | yeah, no kidding |
| 07:57 | <mcarter> | another thing to remember is that you can have proxy chains |
| 07:58 | <mcarter> | so the client might send an HTTP CONNECT addr:port\r\n\r\n to proxy A, and then proxy A will send HTTP CONNECT addr:port\r\n\r\n to proxy B, and proxy B would actually open the connection to the remote server and send any following data |
| 07:58 | <mcarter> | it doesn't actually affect the client implementation or the server implementation |
| 07:58 | <mcarter> | i'm just pointing out that proxy servers can also be proxy clients |
| 07:59 | <Hixie> | yeah |
| 07:59 | <Hixie> | that i found info for iirc |
| 08:04 | <mcarter> | Also, i didn't make it clear in the proposal, but we will always need to do an explicit HTTP CONNECT to the proxy (instead of just sending it an OPTIONS http://example.com/some/url... and letting it do the proxy) is that the Connection: upgrade header is only good for a single hop. It will be stripped out before it gets to the final destination |
| 08:04 | <mcarter> | s/but/but the reason that/ |
| 08:04 | <Hixie> | yeah |
| 08:07 | <takkaria> | hsivonen: thanks |
| 08:08 | <mcarter> | Hixie, Does it look like the name of this thing is going to be DuplexConnection? |
| 08:08 | <hsivonen> | takkaria: fwiw, I've found that CRLF causes a lot of grief. I handle it in the Driver and the Tokenizer has a hiccup back to the Driver on every LF following CR |
| 08:09 | <hsivonen> | this is necessary to make CRLF do the right thing when CR and LF come from different document.writes |
| 08:10 | <hsivonen> | (Driver and Tokenizer as described in my email to public-html yesterday) |
| 08:10 | takkaria | nods |
| 08:10 | <takkaria> | I've been looking at the code for validator.nu and html5lib, they've both been quite helpful |
| 08:11 | <hsivonen> | I changed this on Monday. my previous design sucked |
| 08:12 | <Hixie> | mcarter: no idea on the name |
| 08:12 | <Hixie> | mcarter: i don't know that Duplex is the best work for it |
| 08:14 | <mcarter> | I think TCPConnection would be the easiest to "sell" to developers and by that measure its probably the best aside from SocketConnection or TCPSocket. But as othermaciej said, this is not really a tcp connection |
| 08:15 | <Hixie> | SocketConnection might be ok |
| 08:18 | <mcarter> | think about it at any rate. I vote for SocketConnection over DuplexConnection |
| 08:18 | <mcarter> | I'm about to start a series of articles introducing Orbited and its approximate implementation of the specification, but i should probably hold off until we nail the name down |
| 08:19 | <mcarter> | There is a surprising amount of interest in having some kind of socket connection in the browser though |
| 08:20 | <Hixie> | not surprising to me :-) |
| 08:20 | <Hixie> | what surprises me actually is how many people claim lack of interest |
| 08:21 | <mcarter> | yeah, thats a good point |
| 08:21 | <mcarter> | if this sort of thing catches on it could completely change the way web applications are written. I mean, no more ruby on rails / php / java servelets |
| 08:21 | <Hixie> | yup |
| 08:22 | <Hixie> | i'm already faking it on my own apps |
| 08:22 | <Hixie> | i have a tcp socket server, and then two cgi scripts |
| 08:22 | <mcarter> | are you doing polling or long polling or something? |
| 08:22 | <Hixie> | one just listens to the tcp server, and passes everything through as <script> blocks |
| 08:22 | <Hixie> | the other accepts POSTs and connects to the tcp server, pushes that message, and disconnects |
| 08:23 | <mcarter> | heh, thats what orbited does |
| 08:23 | <Hixie> | but once we can connect directly those tw ocgis can go away and be replaced with a single connection |
| 08:23 | <Hixie> | how about OrbitedConnection? ;-) |
| 08:23 | <mcarter> | haha |
| 08:23 | <mcarter> | That would scare a number of people away i think |
| 08:23 | <Hixie> | hah |
| 08:24 | <mcarter> | I'm trying to get all these Comet people to come around to the idea of using something mroe like a socket |
| 08:24 | <mcarter> | they've all gone and built these crazy scheme's around the notion that comet is some special thing |
| 08:24 | <mcarter> | but really, they just want a SocketConnection |
| 08:24 | <Hixie> | yeah i don't understand the comet people |
| 08:24 | <Hixie> | they're worse than the ajax people! |
| 08:24 | <Hixie> | and those are already worse than the dhtml and rest people |
| 08:25 | <hsivonen> | Hixie: how strict are you about the couple of lines of Perl req? |
| 08:25 | <mcarter> | I actually have an 8-9 part back and forth with the Bayeux/cometd guys on cometdaily.com explaining from the ground up how we really just want a socket |
| 08:25 | <Hixie> | hsivonen: i don't believe i said "a couple" |
| 08:25 | <hsivonen> | ok |
| 08:25 | <Hixie> | hsivonen: i just don't want to write an HTTP server with thousands of lines |
| 08:25 | <mcarter> | Hixie, the exact quote was "a few" ;-) |
| 08:26 | <Hixie> | btw this new protocol does rather do away with the broadcast connection and local peer to peer ideas |
| 08:26 | <Hixie> | but i guess that's ok |
| 08:26 | <hsivonen> | I wonder if we could get someone champion an Apache module or something that deals with complexity from Day 1 |
| 08:26 | <mcarter> | i was thinking about that |
| 08:26 | <mcarter> | peer connections would be brilliant |
| 08:26 | <mcarter> | and flash 10 has them, doesn't it? |
| 08:26 | <mcarter> | I'm not convinced you should rip them out of the specification just yet |
| 08:28 | <Hixie> | hsivonen: "day 1" would be about 3 years ago, if we want stuff actually deployed and usable :-) |
| 08:28 | <Hixie> | hsivonen: servers take even longer to upgrade than clients |
| 08:29 | <Hixie> | mcarter: well, what's the use case? |
| 08:29 | <mcarter> | distributed file sharing for one |
| 08:29 | <Hixie> | in a web app? |
| 08:29 | <mcarter> | sure |
| 08:30 | <mcarter> | if you can broadcast on your lan to detect other clients, and then establish peer connections, you can do ANYTHING |
| 08:30 | <mcarter> | make games that don't need servers |
| 08:30 | <mcarter> | your whole app could just be a .html file |
| 08:30 | <Hixie> | does anyone really hang out on the same lan these days? |
| 08:31 | <mcarter> | good point. they do in college/university, and not so much later |
| 08:31 | <mcarter> | on the other hand, LAN parties are still prevelant for gaming |
| 08:33 | <Hixie> | krijnh: i apologise for #webapps |
| 08:33 | <krijnh> | Hixie: np ;) |
| 08:34 | <Hixie> | krijnh: there's something about the w3c that makes people act weird |
| 08:34 | <krijnh> | I did expect your apology though |
| 08:34 | <Hixie> | heh |
| 08:34 | <mcarter> | How about distributed caching? If you could implement a way for the server to just send you a HASH of a resource and then have the browser check the LAN for someone else with that resource, you could save TONS of bandwidth |
| 08:35 | <mcarter> | I'm not sure if javascript is the right place for that sort of feature, probably it should be built into the browser directly, if at all. On the other hand, it would be great to open experimentation up to EVERYONE and not just browser developers |
| 08:40 | <Hixie> | yeah |
| 08:40 | <Hixie> | but that's not really enough of a use case to justify browsers implementing that feature |
| 08:41 | <Hixie> | since they could just implement the caching |
| 08:50 | <Hixie> | mcarter: so this doesn't address the framing problem, btw |
| 08:52 | <krijnh> | Yay, Dmitry Turin is back :) |
| 08:52 | <Hixie> | i guess we can just strip U+0000 characters and use that as a frame terminator |
| 08:52 | <mcarter> | Hixie, well, I'm still against having framing in the protocol, or at least I'm against it being non-optional. But I'd much rather have the connection with framing than no connection |
| 08:52 | <Hixie> | and have the first byte of each frame be an indicator of the kind of data |
| 08:52 | <Hixie> | we need framing for two reasons |
| 08:53 | <Hixie> | one is future compatibility, when we add raw binary data to the web platform, so you can transmit raw binary data as well as UTF-8 data |
| 08:53 | <Hixie> | the other is specifically server->client, so that the client knows when to fire the events |
| 08:53 | <Hixie> | we don't want to have everyone reimplement packet fragment reassembly manually in js |
| 08:54 | <mcarter> | i was thinking about this |
| 08:54 | <mcarter> | i think it would be better off to make a seperate api/protocol for text and binary |
| 08:54 | <Hixie> | really? |
| 08:54 | <mcarter> | or at the very least, have it specified in the initial handshake |
| 08:54 | <Hixie> | seems like you'd want both in the same connection |
| 08:55 | <Hixie> | e.g. to transmit text and pictures in a chat |
| 08:55 | <mcarter> | really i think it should always be binary and you should just have access to a utf-8 decoder |
| 08:56 | <Hixie> | you have more faith in web authors than i do |
| 08:56 | <mcarter> | we have a BinaryTCPConection in orbited and we implemented a utf-8 decoder and it all works out pretty well |
| 08:56 | <mcarter> | you may have a point |
| 08:56 | <Hixie> | you're not exactly representative |
| 08:57 | <Hixie> | and i mean that as a compliment, btw :-) |
| 08:57 | <mcarter> | heh, thanks =D |
| 08:57 | <mcarter> | We could also change the api slightly to allow the option to read the data either way |
| 08:57 | <mcarter> | like, onread doesn't return an event with data, but specifies that you should call read() to actually get the data |
| 08:58 | <Hixie> | we need to know if the packet is binary or text when sending, so we know it anyway, so we might as well pass that along |
| 08:58 | <Hixie> | also, we need to know it so that we know how to find the end of the frame |
| 08:58 | <Hixie> | e.g. UTF-8 will never include a raw 0x00 or 0xFF byte, so we can use those for framing |
| 08:59 | <Hixie> | but binary will include both, so we either want to use a size indicator, or a way to escape the frame terminator |
| 08:59 | <mcarter> | i am partial to the size indicator |
| 09:00 | <Hixie> | yeah escaping frame terminators is bad from a perf point of view |
| 09:00 | <mcarter> | the reason to use the delimiters i guess is to make it easier to implement the server, right? |
| 09:00 | <Hixie> | yes |
| 09:00 | <Hixie> | amongst other reasons |
| 09:01 | <Hixie> | size indicators, on the other hand, put an upper limit on the amount of data you can send per frame |
| 09:01 | <Hixie> | and are inefficient for smallmessages |
| 09:01 | <mcarter> | True |
| 09:02 | <mcarter> | I really don't like the idea of having to escape those characters for binary transfer though |
| 09:02 | <Hixie> | on the plus side, size indicators tend to make it less likely to have buffer overruns |
| 09:02 | <mcarter> | you know, the STOMP protocol uses both methods |
| 09:02 | <Hixie> | since you're less likely to guess a size |
| 09:02 | <Hixie> | using both gets you the worst of both world and not the best of either :-) |
| 09:03 | <mcarter> | they say that if there is no frame size specified (header based) then look for 0x00, and otherwise use the specified frame size |
| 09:03 | <Hixie> | aah |
| 09:03 | <Hixie> | that makes sense |
| 09:03 | <Hixie> | what i was thinking earlier is that each frame would start with a type byte |
| 09:03 | <Hixie> | 0x00 = UTF-8, terminated by 0x00 |
| 09:03 | <Hixie> | 0x01 = binary, followed by 32 bit integer N, followed by N bytes of data |
| 09:04 | <mcarter> | yeah, that could work pretty well |
| 09:05 | <mcarter> | are we allowing alternating frame types then? |
| 09:05 | <mcarter> | right, you just said that |
| 09:05 | <mcarter> | sending pictures and text on the same connection |
| 09:06 | <Hixie> | or we could represent the integer N using 7 bits per byte, with the 8th bit being set if there is another byte |
| 09:06 | <Hixie> | that lets us have arbitarily sized frames |
| 09:06 | <Hixie> | without high overhead for small frames |
| 09:06 | <mcarter> | sort of utf-8-esque |
| 09:06 | <Hixie> | yeah |
| 09:07 | <mcarter> | yeah, that would work |
| 09:07 | <Hixie> | so 127 byte frames are 0x01 0x7F data |
| 09:07 | <Hixie> | and a 128 byte frame would start 0x01 0x80 0x01 data |
| 09:07 | <mcarter> | and 256 byte frames are 0x01 0xFF 0x01 data |
| 09:07 | <Hixie> | right |
| 09:08 | <Hixie> | actually that would be 255 |
| 09:08 | <Hixie> | 256 would be 0x01 0xFF 0x02 data |
| 09:08 | <mcarter> | yeah, right. |
| 09:08 | <mcarter> | we start at 0 |
| 09:08 | <mcarter> | though, 0 should mean 1 byte, right? |
| 09:08 | <Hixie> | er no, 0x01 0x80 0x02 |
| 09:08 | <Hixie> | or something |
| 09:08 | <Hixie> | hm |
| 09:08 | <Hixie> | i suppose we could just add one to the length, yes |
| 09:09 | <Hixie> | although |
| 09:09 | <Hixie> | i could see uses for sending zero byte packets |
| 09:09 | <Hixie> | so maybe not |
| 09:09 | <Hixie> | (e.g. sending a file that's zero bytes wouldn't need special casing this way: 0x00 FILENAME.DAT 0x00 0x01 0x00 |
| 09:11 | <mcarter> | that makes sense |
| 09:12 | <mcarter> | even if there weren't cases for it, the confusion of being off by one is probably not worth extending our range by 1 |
| 09:13 | <mcarter> | whats the api like for send then? sendText and sendBytes ? or send(data) and then the browser detects the type of data |
| 09:13 | <Hixie> | sendText(s) for now |
| 09:14 | <Hixie> | sendBlob(blob) later when we have blob objects |
| 09:14 | <Hixie> | those are still being specified |
| 09:14 | <Hixie> | but they'll affect everything, xhr, file upload, SocketConnection, the works |
| 09:14 | <Hixie> | Database |
| 09:15 | <mcarter> | yeah. For now we'll limp along in Orbited with OrbitedBinarySocketConnection with a sendBytes function |
| 09:15 | <Hixie> | :-) |
| 09:16 | <mcarter> | are there any plans for exposing to javascript some of the built-in decoders for images or text? |
| 09:16 | <mcarter> | or encryption |
| 09:16 | <mcarter> | I was saying the other day that we're having a hell of a time implementing TLS in the browser for xmpp over our faux Binary connection |
| 09:16 | <Hixie> | no idea, the blob stuff is still very very new |
| 09:17 | <Hixie> | and i'm not really involved |
| 09:17 | <Hixie> | though i might end up having to spec it myself! :-) |
| 09:17 | <mcarter> | oh hey, i still want to setup some kind of social meeting for whatwg/html5 at some point |
| 09:17 | <mcarter> | I just moved to mountain view this week |
| 09:18 | <mcarter> | I'll send an email out and put a wiki up I guess |
| 09:18 | <mcarter> | is there already a wiki somewhere that whatwg uses? |
| 09:19 | <Hixie> | nice! |
| 09:19 | <Hixie> | wiki.whatwg.org |
| 09:20 | <mcarter> | cool, I'll put it up there |
| 09:20 | <Hixie> | i should sleep |
| 09:20 | <Hixie> | thanks for the help |
| 09:20 | <Hixie> | i'll definitely work on this after the url stuff |
| 09:21 | <Hixie> | though that is proving quite tedious |
| 09:21 | <Hixie> | so might take a while |
| 09:21 | <Hixie> | nn |
| 09:21 | <zcorpan> | should HTMLVideoElement.EMPTY be defined? |
| 09:22 | <mcarter> | ok, well good luck with that URL stuff. goodnight |
| 09:22 | <doublec> | zcorpan, isn't it defined in HTMLMediaElement? |
| 09:22 | <zcorpan> | doublec: yes but i haven't wrapped my head around how inheritance works |
| 09:23 | <zcorpan> | should there just be HTMLMediaElement.EMPTY, HTMLMediaElement.prototype.EMPTY and HTMLVideoElement.prototype.EMPTY and not HTMLVideoElement.EMPTY? |
| 09:26 | <doublec> | yes |
| 09:26 | <doublec> | afaik |
| 09:28 | <zcorpan> | k |
| 09:28 | <zcorpan> | seems to agree with Node.ELEMENT_NODE |
| 09:29 | <Dashiiiva> | Constants should be on the interface object and the interface prototype object, but not on objects implementing the interface |
| 09:30 | Hixie | briefly pops back online to record that "WebSocket" would probably be a good new name for the TCPConnection object |
| 09:30 | <zcorpan> | Dashiiiva: why not on objects implementing the interface? |
| 09:31 | <Dashiiiva> | Because they have the interface prototype object as their prototype, so they inherit it there |
| 09:32 | <takkaria> | hsivonen: ping; when I've written new tests for the tokeniser, where's the best place to put them so others can make use of them? |
| 09:32 | <zcorpan> | Dashiiiva: but the end result is that the constant is present on the object? |
| 09:32 | <takkaria> | hsivonen: (I ask because you seem to know about such things) |
| 09:32 | <Dashiiiva> | somevideo.EMPTY works, yes |
| 09:32 | <hsivonen> | takkaria: the html5lib svn repo |
| 09:33 | <hsivonen> | under testdata/tokenizer/ |
| 09:33 | <hsivonen> | preferably in the same format |
| 09:33 | <zcorpan> | Dashiiiva: ok |
| 09:33 | <Dashiiiva> | zcorpan: I suppose we don't use the same definition of present :) |
| 09:33 | <takkaria> | hsivonen: who can I poke to get commit access? |
| 09:34 | <zcorpan> | Dashiva: black-box testing says it's present :) |
| 09:34 | <hsivonen> | takkaria: annevk or jgraham_ |
| 09:34 | <takkaria> | hsivonen: thanks! |
| 09:34 | <Dashiiiva> | zcorpan: I would consider present to mean it has an own property, but you seem to mean own or inherited. So yeah. |
| 09:35 | <zcorpan> | Dashiiiva: ah |
| 09:35 | zcorpan | doesn't know about an own property |
| 09:36 | <Dashiiiva> | heycam: Those italic capital I (for example interfaces) look really like slashes in b4d :) |
| 09:36 | <zcorpan> | Dashiva: is the own property exposed to authors somehow? |
| 09:38 | <Dashiiiva> | zcorpan: You can use hasOwnProperty to detect whether a property is inherited or not |
| 09:42 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Aw(Node.ELEMENT_NODE.hasOwnProperty())%0Atry%20{%20w(Node.prototype.ELEMENT_NODE.hasOwnProperty())%20}%20catch(e)%20{%20w(e)%20}%0Aw(Element.prototype.ELEMENT_NODE.hasOwnProperty())%0Aw(document.documentElement.ELEMENT_NODE.hasOwnProperty())%0A%3C%2Fscript%3E |
| 09:42 | <zcorpan> | firefox: false, exception, false, false |
| 09:42 | <zcorpan> | opera, safari: false, false, false, false |
| 09:42 | <zcorpan> | are they all wrong? :) |
| 09:43 | <Dashiiiva> | element.hasOwnProperty(propname) |
| 09:43 | <zcorpan> | ah |
| 09:44 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Aw(Node.hasOwnProperty(%27ELEMENT_NODE%27))%0Aw(Node.prototype.hasOwnProperty(%27ELEMENT_NODE%27))%0Aw(Element.prototype.hasOwnProperty(%27ELEMENT_NODE%27))%0Aw(document.documentElement.hasOwnProperty(%27ELEMENT_NODE%27))%0A%3C%2Fscript%3E |
| 09:45 | <zcorpan> | firefox: true false true false |
| 09:45 | <zcorpan> | opera, safari: true true false false |
| 09:45 | <Dashiiiva> | Huh... what's firefox doing... |
| 09:46 | <zcorpan> | is true true true false expected? |
| 09:46 | <Dashiiiva> | Ye |
| 09:46 | <Dashiiiva> | Node is an interface object, Node.prototype is the corresponding interface prototype object. |
| 09:49 | <zcorpan> | is this defined somewhere? |
| 09:49 | <zcorpan> | hasOwnProperty i mean |
| 09:49 | <zcorpan> | es4? |
| 09:50 | <Dashiiiva> | es3 |
| 09:51 | <Dashiiiva> | Element.ELEMENT_NODE should be undefined (neither own nor inherited) going by the current B4D. |
| 09:52 | <Dashiiiva> | I suppose that makes sense |
| 09:52 | <philipj> | how about Element.prototype.ELEMENT_NODE? |
| 09:52 | <Dashiiiva> | That's inherited from Node.prototype.ELEMENT_NODE |
| 09:52 | <philipj> | then all is well, it would seem |
| 09:53 | <Dashiiiva> | Yeah, I just assumed (for no reason) the interface objects would inherit each other like the prototype objects do |
| 09:54 | <annevk> | sigh |
| 09:54 | <annevk> | part of my bike broke so I couldn't use it :/ |
| 09:55 | <annevk> | well, howcome's bike |
| 09:55 | <philipj> | what puzzles me a little is what part of what spec says that Node.ELEMENT_NODE is defined, is it the constness? |
| 09:56 | <jgraham__> | takkaria: What's your email (pref. gmail) address? I can add you as a html5lib project member# |
| 09:57 | <annevk> | philipj, DOM Core does, though not that Node is exposed on the global object... |
| 09:57 | <Dashiiiva> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Afunction%20wel(el)%20{%0Avar%20elname%20%3D%20el.toString()%3B%0Aw(%20elname%20%2B%20%27%3A%20%27%20%2B%20el.hasOwnProperty(%27ELEMENT_NODE%27)%20%2B%20%27%20-%20%27%20%2B%20el[%27ELEMENT_NODE%27])%3B%0Ael%20%3D%20el.prototype%3B%0Aw(%20elname%20%2B%20%27%20prototype%3A%20%27%20%2B%20el.hasOwnProperty(%27ELEMENT_NODE%27)%20%2B%20%27%20-%20%27%20%2B%20el[ |
| 09:57 | <Dashiiiva> | %27ELEMENT_NODE%27])%3B%0A}%0Avar%20els%20%3D%20[%20Node%2C%20Element%2C%20document.documentElement%20]%0Afor%20(%20var%20i%20%3D%200%2C%20el%3B%20el%20%3D%20els[i]%3B%20%2B%2Bi%20)%20{%20wel(el)%3B%20}%0A%3C%2Fscript%3E |
| 09:57 | <Dashiiiva> | ow |
| 09:58 | <philipj> | () should really be escaped |
| 09:58 | <takkaria> | jgraham__: takkaria⊙gc |
| 09:58 | <Dashiiiva> | Needs an automatic tinyurl permalink as well :) |
| 09:59 | <annevk> | Dmitry is back! |
| 09:59 | <annevk> | so much more awesome than RB |
| 09:59 | <jgraham__> | takkaria: OK, done |
| 09:59 | <takkaria> | jgraham__: thanks! |
| 09:59 | <takkaria> | though the current tests seem pretty exhaustive, I'm not sure I've much to add |
| 10:02 | <krijnh> | annevk: indeed :) |
| 10:04 | <hsivonen> | http://lists.w3.org/Archives/Public/wai-xtech/2008Jun/0062.html |
| 10:05 | <takkaria> | look like good reasons to drop accesskeys and tabindexes :) |
| 10:05 | <annevk> | seems UA issues |
| 10:05 | <annevk> | most solved on mobile phones, too |
| 10:15 | <Dashiiiva> | zcorpan: I suppose you could file a bug on firefox that they define the Node constants on Element instead. |
| 10:15 | <zcorpan> | Dashiiiva: i could, but i rather write more tests :) |
| 10:17 | <Dashiiiva> | zcorpan: Because I was bored: http://tinyurl.com/58ujom |
| 10:25 | <annevk> | regarding #webapps IRC logging: http://www.w3.org/mid/op.ucxtwtuf64w2qv⊙aooc |
| 10:26 | <krijnh> | 404 |
| 10:26 | <annevk> | bah, /mid/ zuigt |
| 10:26 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0222.html |
| 10:27 | <krijnh> | Yay, the first time my name is mentioned inside an e-mail on lists.w3.org |
| 10:28 | <krijnh> | I should rename 'HTML5 IRC logs' |
| 10:29 | <annevk> | Web Platform IRC logs |
| 10:29 | <annevk> | though searching for html5 irc is convenient sometimes :) |
| 10:30 | <krijnh> | 'irc logs' is shorter :) |
| 10:30 | <krijnh> | Third position in Google, thanks for all the linklove everybody! |
| 10:31 | <annevk> | we rely on you not selling that part of your domain for a million dollars :D |
| 10:31 | <krijnh> | Heh |
| 10:31 | <krijnh> | I should put up some ads there |
| 10:31 | <annevk> | :evil: |
| 10:32 | <krijnh> | Didn't you have ads on your site as well? |
| 10:32 | <krijnh> | <!doctype html> <-- why two spaces? |
| 10:32 | <annevk> | I did, yeah |
| 10:33 | <annevk> | but I'm not running a community service |
| 10:33 | <krijnh> | Ow, I am? |
| 10:33 | <krijnh> | It's a Web 2.0 application, damnit |
| 10:46 | <krijnh> | There, a new title, and some shiny subtitles |
| 10:47 | <annevk> | hehe, I like the switching subtitle |
| 10:50 | <hsivonen> | hmm. I see that #xhtml is no longer logged |
| 10:50 | <hsivonen> | not kick ass enough? |
| 10:50 | <krijnh> | annevk: There are 11 :) |
| 10:51 | <krijnh> | hsivonen: MikeSmith asked me to not show them anymore |
| 10:51 | <krijnh> | The logs are still up, but I'm not in that channel anymore |
| 10:52 | <hsivonen> | krijnh: interesting |
| 10:53 | <krijnh> | MikeSmith probably knows the interesting parts :) |
| 10:54 | <MikeSmith> | no interesting parts |
| 10:55 | <MikeSmith> | just a complaint to me about why "we" were logging the #xhtml2 channel |
| 10:56 | <MikeSmith> | noticing that XHTML2 WG doesn't actually seem to be using that channel for much of anything anymore |
| 10:56 | <annevk> | because "we" are spying, duh |
| 10:56 | <MikeSmith> | heh |
| 10:56 | <Lachy> | it was so that we could keep an eye on them to see what they were up to. |
| 10:56 | <Lachy> | I'm still in the channel, but I haven't paid much attention to it for ages. |
| 10:57 | <MikeSmith> | well, figured a good way to get that out of my complaint queue was to ping krijnh and ask if we could take it off the the "interesting" channels page |
| 10:58 | <krijnh> | You should also tell it did cost you some money |
| 10:58 | <krijnh> | Before people think I'm too easy |
| 11:03 | <MikeSmith> | krijnh: btw, I know I probably asked you this before, but how do you pronounce your name? |
| 11:03 | <Lachy> | MikeSmith, who complianed? |
| 11:03 | <MikeSmith> | Lachy: does it matter? |
| 11:03 | <krijnh> | MikeSmith: a combination of 'crane' and 'whine' |
| 11:04 | <Lachy> | no, just curious |
| 11:04 | <hsivonen> | aargh. I have an IO bug in code that I haven't changed recently |
| 11:04 | <MikeSmith> | krijnh: thanks |
| 11:04 | <hsivonen> | very weird |
| 11:04 | <krijnh> | (MikeSmith: my first name at least) |
| 11:04 | <MikeSmith> | krijnh: I won't ask about your last name for now. First name enough of a challenge for me :) |
| 11:04 | <krijnh> | Heh |
| 11:05 | <MikeSmith> | one great thing about Japanese names is pronunciation is always unambiguous |
| 11:05 | <krijnh> | There goes my international fame, thank you mom and dad |
| 11:05 | <MikeSmith> | heh |
| 11:05 | <hsivonen> | oops. the IO bug was in code I wrote this week |
| 11:05 | <hsivonen> | whew |
| 11:06 | <krijnh> | Why is height="" and width="" not allowed on <input> btw? |
| 11:06 | <MikeSmith> | hsivonen: now you still got a bug to fix |
| 11:06 | <krijnh> | Makes sense for <input type="image"> |
| 11:06 | <hsivonen> | MikeSmith: already fixed |
| 11:07 | <krijnh> | <input type="image" src="transparent.png" height="10" width="10" style="background:transparent url(sprites.png) no-repeat 10px 10px"> would be a use case |
| 11:07 | <krijnh> | (For html4all people reading this, yes, I would include alt="Foo") |
| 11:08 | <MikeSmith> | krijnh: I tink the idea is that you should use CSS for that |
| 11:08 | <MikeSmith> | hmm |
| 11:08 | <MikeSmith> | or maybe not |
| 11:09 | <krijnh> | I don't know :) |
| 11:09 | <MikeSmith> | hey man |
| 11:09 | <krijnh> | Perhaps I should post it to the list, so Hixie can dismiss my proposal, without even bothering to look at it! |
| 11:09 | <krijnh> | That would be fun |
| 11:09 | <MikeSmith> | read the spec |
| 11:09 | <MikeSmith> | http://www.w3.org/TR/html5/embedded0.html#the-img |
| 11:10 | <krijnh> | What about it? |
| 11:10 | <MikeSmith> | Element-specific attributes: |
| 11:10 | <MikeSmith> | alt |
| 11:10 | <MikeSmith> | src |
| 11:10 | <MikeSmith> | usemap |
| 11:10 | <MikeSmith> | ismap |
| 11:10 | <MikeSmith> | width |
| 11:10 | <krijnh> | Yeah, for <img> |
| 11:10 | <MikeSmith> | height |
| 11:10 | <MikeSmith> | oh shit |
| 11:10 | <MikeSmith> | sorry |
| 11:10 | <krijnh> | :) |
| 11:10 | <MikeSmith> | confused |
| 11:10 | <MikeSmith> | tired |
| 11:10 | <MikeSmith> | hungry |
| 11:11 | <MikeSmith> | pissed |
| 11:11 | <MikeSmith> | clearly time for me to take a beer break |
| 11:12 | <Dashiiiva> | only in Japan |
| 11:14 | <MikeSmith> | one may also enjoy to occasional breakfast beer |
| 11:14 | <MikeSmith> | "one" meaning "me" |
| 11:15 | <MikeSmith> | anybody know where stands Adam Barth's "HTML 5 should expose a native JSON parser for web content." proposal? |
| 11:15 | <MikeSmith> | did it get some bites? |
| 11:16 | MikeSmith | re-reads the thread |
| 11:17 | <MikeSmith> | "A motivated browser maker need not wait for ECMA's formal approval." |
| 11:17 | <MikeSmith> | indeed |
| 11:18 | <MikeSmith> | do json2.js or ES3.1 have any traction? |
| 11:19 | <MikeSmith> | or are they just things that Doug Crockford is personally promoting? |
| 11:19 | <MikeSmith> | ah |
| 11:19 | <MikeSmith> | remembering now |
| 11:19 | <MikeSmith> | or re-reading now |
| 11:20 | <Dashiiiva> | I don't know about json2.js, but json in general has traction |
| 11:21 | <MikeSmith> | Dashiiiva: yeah, realize that |
| 11:21 | <annevk> | krijnh, does height/width work on image in browsers? I guess it probably does. Anyways, that's a WF2 feature which hasn't been looked at for quite a while |
| 11:22 | <krijnh> | On <input type="image"> you mean? |
| 11:22 | <krijnh> | Yeah, it does |
| 11:22 | <krijnh> | And it's silly they are reported as errors |
| 11:23 | <krijnh> | But I'm sure hsivonen already mentioned this, or will |
| 11:28 | <hsivonen> | krijnh: I think width/height on input type=image has escape my radar |
| 11:28 | <hsivonen> | +d |
| 11:29 | <krijnh> | I added some messages to your logs yesterday, I think |
| 11:29 | <krijnh> | Do you agree they should be conforming? |
| 11:30 | hsivonen | doesn't read the logs that actively |
| 11:30 | <hsivonen> | krijnh: yeah, I think they should be conforming |
| 11:33 | <hsivonen> | hmm. It seems that System.in in Java can violate some basic assumptions about InputStreams |
| 11:33 | <hsivonen> | that's *not* good |
| 11:35 | <hsivonen> | or I still have a serious IO bug lurking somewhere |
| 11:35 | <hsivonen> | a bug that shows up with System.in but not with files or network |
| 11:48 | <heycam> | Dashiiiva, i'll change it |
| 11:48 | <heycam> | (Dashiiiva gains an 'i' every day, it seems!) |
| 11:55 | <hsivonen> | whee! System.in misbehaves |
| 11:57 | <hsivonen> | looks like System.in loses data if the data doesn't contain any line breaks |
| 11:57 | <hsivonen> | writing a final \n before pressing ^D fixes |
| 11:59 | <Dashiiiva> | heycam: Only when my connection dies and I get a nick collision ;) |
| 13:11 | <heycam> | hsivonen, typing input to System.in from the command line? |
| 13:11 | heycam | just wonders if it's a line-buffering issue |
| 13:13 | <hsivonen> | heycam: typing to System.in in Eclipse's console |
| 13:13 | <hsivonen> | If I type |
| 13:13 | <heycam> | not sure about eclipse's console, but at the command line the terminal is line-buffered by default |
| 13:14 | <hsivonen> | <!DOCTYPE html>foo^D |
| 13:14 | <hsivonen> | I get an empty stream |
| 13:14 | <hsivonen> | but if I put a line break between foo and ^D, it works |
| 13:15 | <hsivonen> | it seems silly if ^D doesn't flush the last line |
| 13:15 | <heycam> | yes but that seems as if the console isn't passing the data to System.in |
| 13:15 | <heycam> | i'd be pretty surprised if it was a bug in InputStream |
| 13:15 | <hsivonen> | yeah |
| 13:16 | <heycam> | if i run something from the command line (e.g. just "cat") and i press ^D before a newline, then it does nothing |
| 13:16 | <heycam> | but if i press ^D^D, then it ends the stream (and sends that line, without the \n on the end) |
| 13:17 | <heycam> | but that behaviour is really just up to the terminal |
| 13:22 | <heycam> | http://rafb.net/p/1ScMvU24.html |
| 13:23 | <heycam> | i guess it's just eclipse console idiosyncrasies |
| 13:25 | <annevk> | hsivonen, is vtab handled specially somewhere? |
| 13:25 | <annevk> | hsivonen, like, in the input stream? |
| 13:25 | annevk | thought all that changed was that it was no longer a space character |
| 13:26 | <hsivonen> | annevk: just making sure when deleting non-obvious code |
| 13:26 | <hsivonen> | annevk: vtab is now the only non-space character that doesn't get the REPLACEMENT CHARACTER treatment below 0x20 |
| 13:29 | <annevk> | hmm, I wonder if that's in line with browsers |
| 13:30 | <hsivonen> | I've now got the tokenizer synced with the spec |
| 13:30 | <hsivonen> | onto the tree builder |
| 13:30 | <zcorpan> | hsivonen: btw, does the vtab checkin only affect the parser? or also non-schema checkers/html5 datatype library? |
| 13:31 | <hsivonen> | zcorpan: the parser has replaced vtab and ff with a space, so the higher layers operate on the XML 1.0 notion of white space |
| 13:31 | <hsivonen> | zcorpan: so, no |
| 13:31 | <zcorpan> | hsivonen: ok |
| 13:32 | <annevk> | interesting |
| 13:32 | <annevk> | that also doesn't sound like browsers |
| 13:32 | <hsivonen> | annevk: it's configurable in the V.nu browser |
| 13:32 | <hsivonen> | annevk: I mean, I'm not going to hack every off-the-shelf XML library to grok HTML5 space characters |
| 13:33 | <hsivonen> | so the RELAX NG engine sees XML 1.0 whitespace |
| 13:33 | <hsivonen> | doh. s/V.nu browser/V.nu parser/ |
| 13:33 | <annevk> | it can't cope with characters not allowed in XML? |
| 13:33 | Philip` | thinks the "just stick an HTML5 parser on the front of your XML toolchain" model seems to be showing a few cracks |
| 13:33 | <hsivonen> | annevk: I'm not sure |
| 13:34 | <hsivonen> | annevk: but whitespace is sensitive to XPath and RELAX NG intra-element white space |
| 13:34 | <hsivonen> | Philip`: how so? the parser papers over the differences |
| 13:36 | <Philip`> | hsivonen: If the parser is replacing vtab and ff with a space, that sounds like undesirable information loss |
| 13:37 | <hsivonen> | Philip`: I see three ways to deal with this, and my parser supports all three |
| 13:38 | <hsivonen> | Philip`: now that vtab is no longer a space char, it turns into a REPLACEMENT CHARACTER in te ALTER_INFOSET mode |
| 13:40 | <hsivonen> | (I'm not gonna support mapping to XML 1.1 or XML 1.0 5th ed.) |
| 14:36 | <annevk> | hsivonen, bugzilla sucks? |
| 14:43 | <zcorpan> | annevk: bugzilla disrupts Hixie from working on URL stuff |
| 14:47 | <annevk> | it does? |
| 14:47 | <annevk> | maybe someone should file a bug on URL stuff then |
| 14:48 | <zcorpan> | http://krijnhoetmer.nl/irc-logs/html-wg/20080618#l-109 |
| 14:48 | <hsivonen> | annevk: bugzilla password renewal email sucks |
| 14:49 | <annevk> | ah, missed that |
| 14:49 | <annevk> | i was thinking about filing a bug on <keygen> the other day |
| 14:49 | <annevk> | so that I don't forget |
| 14:49 | <hsivonen> | oops. my mail filters suck |
| 14:51 | hsivonen | is a bit nervous that that the new block elements are defined to have interaction with implicit </p> |
| 14:51 | <hsivonen> | without a parse error |
| 14:52 | <hsivonen> | so authors can now shoot themselves in the foot with omitted </p> during the transition to HTML5 |
| 14:53 | <zcorpan> | hsivonen: issue warnings? |
| 14:54 | <Lachy> | hsivonen, why is it a problem? |
| 14:54 | <annevk> | it breakz teh Webz |
| 14:55 | <hsivonen> | zcorpan: Yeah. |
| 14:55 | <hsivonen> | zcorpan: in fact, I have a request on file to provide warnigns on implied tags |
| 14:57 | <annevk> | Result: Valid HTML5 |
| 14:57 | <annevk> | Note: implied tags found (learn more, show me) |
| 14:57 | <Lachy> | I fail to see how generating an implied end tag for p when encounting a new element like section will cause back compat problems. |
| 14:58 | <Lachy> | although it will create slightly different DOMs in new browsers compared with current browsers |
| 14:58 | <hsivonen> | Lachy: different DOMs are scary |
| 14:58 | <annevk> | might be a mess with styling |
| 15:00 | <Lachy> | so JS libraries could be used to fix up the DOMs. Just find all section, aside, article, etc., check if any have a P element has a parent and move it. |
| 15:00 | <Lachy> | or just ensure you always use </p> before such an element. |
| 15:01 | <annevk> | <p> ... <section> ... <h1> ends up with <h1> as sibling of <p> |
| 15:01 | <annevk> | the real solution is probably adding support for these elements quickly |
| 15:01 | <hsivonen> | Lachy: well that's my point. if you want to ensure it, a validator doesn't tell you |
| 15:01 | <Lachy> | oh well. |
| 15:02 | <annevk> | because you do want the implied <p> |
| 15:02 | <annevk> | euh, implied </p> |
| 15:02 | <annevk> | having it for <div> and not for <section> would be weird |
| 15:02 | <hsivonen> | oh, I agree that not having it would be weird in the long run |
| 15:07 | <hsivonen> | fun! the algorithms for li, dd and dt have changed |
| 15:18 | <hsivonen> | aargh. AAA step #8 has changed. is it merely editorial? |
| 15:19 | <Philip`> | Changed since when? |
| 15:19 | <Philip`> | I believe there was one non-editorial change since I last looked at it |
| 15:19 | <hsivonen> | Philip`: since March 13th |
| 15:21 | <hsivonen> | since May 13th, too |
| 15:24 | <Philip`> | http://www.w3.org/TR/2008/WD-html5-20080610/diff/tree-construction.html#adoptionAgency |
| 15:26 | <Lachy> | hey, does anyone have any suggestions for example use cases of data-* attributes, that could be used in an article? |
| 15:27 | <Lachy> | The use cases in this article are already covered by the WF2 attributes with the same name http://www.alistapart.com/articles/scripttriggers/ - so that didn't help me much. |
| 15:27 | <hsivonen> | Philip`: it seems to me that the first para of step 8 has changed since the W3C diff |
| 15:28 | <hsivonen> | oops. |
| 15:30 | <hsivonen> | I'm looking at the diff the wrong way round |
| 15:51 | <annevk> | I'm not sure if the not filing bugs in Bugzilla practice works btw. Seems that Hixie files bugs himself to keep himself from doing URL work! Madness |
| 15:55 | <hsivonen> | heh |
| 16:02 | <gsnedders> | jgraham__: Yeah, your impl. is correct per the latest version of the spec |
| 16:08 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=439646 |
| 16:32 | <Philip`> | jgraham__: http://blog.whatwg.org/atmedia-2008 misspells my name |
| 17:05 | <Lachy> | Philip`, where does it get it wrong? |
| 17:06 | <gsnedders> | Lachy: http://lachy.id.au/dev/presentation/hands-on-html5/ — that doesn't credit the photo of me |
| 17:06 | <Philip`> | Lachy: As of twenty seconds ago when I reloaded the page, it doesn't get it wrong anywhere, so that's okay now :-) |
| 17:07 | <gsnedders> | annevk: well, in the case of one of the commits yesterday, I bullied Hixie into it :P |
| 17:07 | <Lachy> | oh, yeah, there are still a few pics I need to add credits for. |
| 17:07 | <Lachy> | I just did the ones I stole from wikipedia and flickr, since they were in my list |
| 17:07 | <gsnedders> | Lachy: The one of me is from Flickr too :P |
| 17:07 | <gsnedders> | http://flickr.com/photos/jgraham/2479527700/ |
| 17:08 | <Lachy> | yeah, but I didn't steal it. I asked for it. |
| 17:08 | <gsnedders> | Ah. |
| 17:08 | <gsnedders> | And taken by your co-presenter |
| 17:08 | <Lachy> | I will have to do it later, after I put my keyboard back together and turn on my PC where the file is located. |
| 17:09 | <gsnedders> | Hixie: The bug is I was taking "Let new candidate section be the section that contains candidate section in the outline of current outlinee." to mean that it was a section that was directly within the outline, and not looking deeper |
| 18:21 | <hsivonen> | w00t. I have the SVG/MathML stuff running locally |
| 18:21 | <hsivonen> | now I need test cases |
| 18:38 | zcorpan_ | reads http://www.w3.org/2008/06/18-xhtml-minutes.html |
| 18:46 | <zcorpan_> | "SM: if FF claims to accept XML and XHTML, why serve text/html" |
| 18:53 | <zcorpan_> | "TH: without a DOCTYPE many tools beome impossible to write, such as accessibility checkers" |
| 18:53 | <hober> | the mind boggles. |
| 18:53 | <zcorpan_> | oh sorry, that was clarified: "<Tina> Without a DOCTYPE many tools becomes impossible to write such that they can deliver trustworthy results. Accessibility checkers is one such example." |
| 18:58 | <zcorpan_> | "SM: issue with HTML-compatible and HTML4 - HTML4-compatible would explicitly exclude HTML5 for better or worse" -- i guess it'd be easier for them to be html5-compatible |
| 18:59 | <zcorpan_> | xmlns and <br/> being two examples (where the latter has incompatible parsing requirements in html4) |
| 19:02 | <zcorpan_> | seems their biggest issues are doctypes and content negotiation |
| 19:02 | <zcorpan_> | or at least that's what they're discussing |
| 19:03 | <zcorpan_> | i don't see what there's to discuss. use <!doctype html> and text/html. done. |
| 19:06 | <mpt> | A few days ago I came across a Web site of a Gnome developer that worked in the KDE browser (Konqueror) but not in the Gnome browser (Epiphany) |
| 19:07 | <mpt> | They had UA sniffing to serve XHTML-as-XML to Gecko, and their XML wasn't well-formed... |
| 19:07 | <zcorpan_> | not uncommon |
| 19:08 | <hsivonen> | interenting time warp there with DTDs |
| 19:08 | <hsivonen> | the XML community at large has generally moved on |
| 19:11 | <zcorpan_> | yeah reading this reminds me of discusions i was having in 2004 when i was learning this |
| 19:11 | <zcorpan_> | discussions |
| 19:14 | <zcorpan_> | seems they'll update appendix c |
| 19:16 | mpt | wonders if one drinks dehydrated water at a Virtual FtF |
| 19:19 | <zcorpan_> | "SP: if need compatability GLs to serve as HTML need lang, but in XHTML lang means nothing and is just there for convenience" |
| 19:19 | <zcorpan_> | hmm i thought lang had the same meaning in xhtml as in html |
| 19:21 | <zcorpan_> | "SP: CSS has knowledge of language text is in due to selector - language comes from parent element of current element; if current element is in latin, do this - only way to do in CSS anyway |
| 19:21 | <zcorpan_> | ... no selector that says if parent of current element has @blah ..." |
| 19:21 | <zcorpan_> | #foo[blah], [blah] #foo |
| 19:29 | <zcorpan_> | "SM: added thing about style HTML element |
| 19:29 | <zcorpan_> | ... in HTML style on body becomes style for entire viewport; in XML does not" |
| 19:29 | <zcorpan_> | not anymore :) |
| 19:30 | <roc> | huh? |
| 19:30 | <roc> | overflow and background on body get propagated to the viewport but nothing else does |
| 19:30 | <zcorpan_> | i meant the "in XML does not" part |
| 19:31 | <zcorpan_> | at least in firefox 3 and opera 9.5 |
| 19:31 | <zcorpan_> | doesn't seem to be fixed in webkit yet |
| 19:31 | <zcorpan_> | http://bugs.webkit.org/show_bug.cgi?id=13568 |
| 19:32 | <roc> | oh, for XHTML documents |
| 19:32 | <zcorpan_> | yeah |
| 19:33 | <zcorpan_> | any webkit guys here? |
| 19:35 | <roc> | we actually have a small regression in Firefox 3 that if you have multiple <body> elements, we propagate from the wrong one. Will be fixed in 3.1. |
| 19:35 | <zcorpan_> | ok. we have some glitches in opera too, but at least we should do the same for both html and xhtml |
| 19:41 | <Hixie> | multiple body elements? |
| 19:41 | <Hixie> | like through DOM manipulation? |
| 19:41 | <Hixie> | or XML? |
| 19:42 | <zcorpan_> | Hixie: either of those, i think |
| 19:42 | <roc> | either |
| 19:42 | <Hixie> | k |
| 19:42 | <Hixie> | not a high priority bug then :-) |
| 19:42 | <roc> | right |
| 19:46 | <Dashiva> | That's a lot of X's removed in 1782 |
| 19:53 | <Hixie> | moved not removed |
| 19:54 | <Dashiva> | What about the big one, like 40 in a row? |
| 19:54 | <Hixie> | it was moved lower |
| 19:55 | <Hixie> | that big line is my bookmark |
| 19:55 | <Hixie> | indicates how far i've gotten in annotating the url changes |
| 19:55 | <Dashiva> | ah |
| 19:55 | <zcorpan_> | "<ShaneM> I think stepping directly to XForms for xhtml 1.2 would be too far." |
| 19:56 | <zcorpan_> | "SM: anything put into XHTML 1.2 should work in browsers today" |
| 19:56 | <zcorpan_> | cool, perhaps they could add <canvas> or something |
| 19:57 | <takkaria> | that line isn't equivalent to "things that work in browsers today should be put into XHTML 1.2" :) |
| 19:58 | <zcorpan_> | indeed |
| 19:58 | <Hixie> | which browsers? do they include IE? |
| 19:58 | <Hixie> | because they'd have to remove the xml part of they did |
| 19:58 | Hixie | ducks |
| 19:58 | takkaria | grins |
| 19:59 | <Hixie> | i wonder which will be done first, xhtml 1.2, or xhtml 5 |
| 19:59 | <Hixie> | though i guess that depends on whether you consider the vague implications that xhtml1.1 consists of to be "done" |
| 20:00 | <Dashiva> | So, does 1.2 replace 2? Or is it like es3.1 and es4? |
| 20:00 | <Hixie> | es4 is supposed to be a superset of es3.1 |
| 20:00 | <Hixie> | so it's clearly not like that |
| 20:00 | <Hixie> | it's more like es3.1 and vbscript |
| 20:00 | <zcorpan_> | Hixie: they'll allow it to be served as text/html if it's "HTML4-compatible", if i understand the notes correctly (or perhaps that wasn't about 1.2) |
| 20:01 | <Hixie> | zcorpan_: i sure hope they define parsing then! |
| 20:01 | <Hixie> | anyway i really must go before i insult someone |
| 20:01 | <Hixie> | bbiab |
| 20:01 | <Lachy> | damn! I was waiting for the insults :-) |
| 20:01 | <zcorpan_> | Dashiiiva: "SP: wrap all those up into a language called XHTML 1.2 so people can refer to markup language that uses these things |
| 20:01 | <zcorpan_> | ... another reason, makes step to XHTML2 that much smaller |
| 20:01 | <zcorpan_> | ... community needs to be led step-by-step to XHTML2 rather than just being presented with it - get used to concepts" |
| 20:02 | <Dashiva> | Maybe I should get a different nick for my work IRC client after all... |
| 20:02 | <zcorpan_> | Hixie: parsing of html4 is defined in sgml |
| 20:03 | <zcorpan_> | s/ii// |
| 20:03 | <hsivonen> | I don't see the point in aiming for what already exists if the spec doesn't specify the existing features in such detail that a new browser could be implemented to spec |
| 20:04 | <zcorpan_> | hsivonen: the point, aiui, is to lead the community step-by-step to xhtml2 |
| 20:05 | <zcorpan_> | but obviously minutes are generally bad and i wasn't there so i could be misunderstanding the motivation |
| 20:06 | <Lachy> | interestingly, there doesn't appear to be any email about it on their mailing list. |
| 20:10 | <Dashiva> | And this happens just after they ask for #xhtml2 not to be logged? ;) |
| 20:11 | <zcorpan_> | too bad they have their own logs public then! |
| 20:12 | virtuelv | is following discussion on wheel events |
| 20:13 | <Dashiva> | discussion... on wheels! |
| 20:13 | Dashiva | apologizes for the wiki injoke |
| 20:13 | <zcorpan_> | "Gregory: That is part of the problem |
| 20:13 | <zcorpan_> | ... there is a difference in how HTML5 and XHTML treat role" -- http://www.w3.org/2008/06/17-xhtml-minutes.html |
| 20:13 | <virtuelv> | Dashiva: related to cobol on cogs? |
| 20:13 | <zcorpan_> | hmm... what's the difference? |
| 20:13 | <Dashiva> | No, related to Willy on Wheels |
| 20:14 | <virtuelv> | I just wish they'd get it over and specify it as an angle and a delta value |
| 20:14 | <virtuelv> | because I'm dead sure that someone is going to put a trackball in there some day instead of the wheel |
| 20:14 | <zcorpan_> | fwiw, for log readers, the equivalent html5+aria would be <span class="checkbox" id="chbox1" role="checkbox" aria-checked="true" tabindex="0"> |
| 20:15 | <zcorpan_> | i.e. no difference from xhtml+aria |
| 20:17 | <zcorpan_> | "Roland: We have a mess as it is |
| 20:17 | <zcorpan_> | ... we can't create a clean version for the future if we don't use the mechanisms that exist" |
| 20:19 | <zcorpan_> | reminds me of how hsivonen said it; the w3c will look stupid for having designed a mechanism that can't be used (paraphrasing from memory) |
| 20:21 | <Dashiva> | "We have to stand up for the rights of the author" |
| 20:21 | <Dashiva> | So forcing inconsistencies and all kinds of trouble is standing up for the authors |
| 20:21 | <hsivonen> | zcorpan_: that wasn't me. that was Hixie |
| 20:22 | <zcorpan_> | hsivonen: oh, ok, sorry |
| 20:42 | <zcorpan_> | this dmitry thing gets me wondering |
| 20:42 | <zcorpan_> | if an alternative place is set up for proposals |
| 20:42 | <zcorpan_> | how are people to know if they should post there or to the list? |
| 20:43 | zcorpan_ | is reading www-archive |
| 20:46 | <Hixie> | zcorpan_: if they rely on sgml, then they'll never exit cr unless they cheat |
| 20:46 | <Hixie> | zcorpan_: and sgml doesn't define error handling |
| 20:47 | <Hixie> | zcorpan_: rb and d post to that thing, and everyone else to the list? :-) |
| 20:47 | <hsivonen> | does XHTML Basic 1.1 inputmode have a second interoperable implementation yet? or any public implementation at all? |
| 20:48 | <Philip`> | SGML defines what is an error, so a document with SGML errors is not HTML4 and so it's not HTML4-compatible XHTML and so it's not XHTML and it's out of scope to define what all non-XHTML bytestreams in the world mean |
| 20:48 | <zcorpan_> | Hixie: i guess they won't require UAs to support sgml or html4 |
| 20:50 | hsivonen | wonders if *independent* interoperable implementations on anything SGML-based are feasible |
| 20:50 | <Hixie> | Philip`: quite |
| 20:50 | <hsivonen> | at least one of the impls would have to be without James Clark's code to be independent |
| 20:50 | <Hixie> | anyway |
| 20:50 | <Hixie> | back in the world of actual real spec development... |
| 20:59 | <zcorpan_> | hsivonen: i wonder if it's good or not to briefly explain what the concequences are of parse errors when it's not what one might expect |
| 21:00 | <hsivonen> | zcorpan_: do you mean in the tree builder? |
| 21:00 | <zcorpan_> | hsivonen: e.g. <div/> or <form><form> |
| 21:00 | <hsivonen> | Yeah, it would be good |
| 21:02 | <zcorpan_> | like, say, "Ignoring the slash." and "Ignoring the form start tag." |
| 21:03 | <hsivonen> | yeah. fixing now |
| 21:03 | <zcorpan_> | cool |
| 21:06 | <hsivonen> | zcorpan_: checked in but deployment will have to wait, because I regressed xmlns talisman and NCName checking when implementing SVG and MathML |
| 21:08 | <zcorpan_> | hsivonen: what's the easiest way to see all the messages that v.nu can emit? check out the code? |
| 21:09 | <hsivonen> | zcorpan_: yeah, checking out the code is the only way |
| 21:09 | <zcorpan_> | hsivonen: ok |
| 21:10 | <hsivonen> | the plan is to migrate the parser to proper string bundles for messages once the messages stabilize or are really needed in a non-English language |
| 21:13 | <mcarter> | it seems that a number of people don't know how to reply back to the list when they respond to a point I've made |
| 21:15 | <hsivonen> | annevk, jgraham_: we should extend the tree builder test format to express namespaced names |
| 21:16 | <hsivonen> | the format extension should be able to distinguis xlink:href as the local name an href in the xlink namespace |
| 21:16 | zcorpan_ | goes to grab some food while build.py is working |
| 21:16 | <hsivonen> | so hard-wired prefixes with the colon may not be the greatest thing |
| 21:17 | <Hixie> | someone let me know if they see jwalden around |
| 21:18 | <zcorpan_> | hsivonen: sdf can do that, but might not be optimal for the purpose. though i can change sdf if you have suggestions :) |
| 21:20 | <hsivonen> | my first instinct says we should just kludge an extension to the current format with prefixes that are sufficiently different from qnames |
| 21:21 | <hsivonen> | like {xlink}href instead xlink:href |
| 21:21 | <hsivonen> | or something |
| 21:23 | <hsivonen> | or xlink=href to use a character that doesn't normally occur in attribute names |
| 21:23 | <Hixie> | mcarter: ok, unless someone raises a clear objection, i'm going to assume we'll use the term Web Socket |
| 21:23 | <Hixie> | with the interface WebSocket |
| 21:24 | <mcarter> | interface and implementation have the same name? |
| 21:24 | <Hixie> | and the protocol Upgrade value WebSocket/1 or some such |
| 21:24 | <Hixie> | right, you'd call new WebSocket(ur); |
| 21:24 | <Hixie> | er |
| 21:24 | <Hixie> | var socket = new WebSocket(url); |
| 21:25 | <mcarter> | sounds great |
| 21:25 | <Hixie> | not sure if the url should be an http: URL or a wsp: URL (wsdp:? wstp:?) |
| 21:25 | <Hixie> | (or just ws: maybe) |
| 21:25 | <Hixie> | since it's not really an HTTP connection you're opening |
| 21:25 | <mcarter> | I went with http in the proposal just because I didn't want to rock too many boats |
| 21:25 | <Hixie> | sure |
| 21:26 | <hsivonen> | hmm. I guess '>' would be the safest delimiter but it is unpleasing aesthetically |
| 21:26 | <Hixie> | luckily, i have my own boat, and am absolutely fine with rocking others! :-D |
| 21:27 | <Hixie> | also so far i'm going to have invented a language, a set of dom interfaces, and a namespace (for xbl) |
| 21:27 | <Hixie> | i might as well add tcp port, uri scheme, and mime types to the list |
| 21:27 | hsivonen | sees that SHAVIAN LETTER IAN has made into the spec |
| 21:27 | <Hixie> | it has? |
| 21:27 | <mcarter> | sound logic as I've ever heard |
| 21:27 | <Hixie> | hah |
| 21:27 | <hsivonen> | Hixie: the SDF spec |
| 21:28 | <hsivonen> | (I thought I was looking at HTML5 for a moment due to the style sheet) |
| 21:28 | <Hixie> | dare i ask what SDF is? |
| 21:28 | <hsivonen> | http://simon.html5.org/specs/sdf |
| 21:28 | <mcarter> | Hixie, I think the framing discussion the other night was on the right track, btw |
| 21:28 | <Hixie> | hsivonen: oh, cool |
| 21:28 | <Hixie> | mcarter: yeah, me too |
| 21:28 | <zcorpan_> | hsivonen: space could work |
| 21:28 | <Hixie> | mcarter: i think this whole thing has legs now, and can fly, to mix metaphors a little. |
| 21:28 | <mcarter> | yeah, it may sail too |
| 21:29 | <Hixie> | :-) |
| 21:29 | <Hixie> | makes sense if we're rocking boats that it would sail, i guess |
| 21:29 | <Hixie> | hey, shavian letter ian really is in this spec, that's funny |
| 21:30 | <hsivonen> | zcorpan_: yeah, space would work |
| 21:30 | <mcarter> | Hixie, for this article I'm writing, at some point do you mind if I ask you for a quote about the new WebSocket standard? |
| 21:30 | <zcorpan_> | i wanted an astral character, and that was the first i found :) |
| 21:31 | <zcorpan_> | i found it in Hixie's signature ;) |
| 21:31 | <Hixie> | mcarter: sure, though it'll be a pretty lame quote in all likelihood, and must be unrelated to google in any way :-) |
| 21:31 | <mcarter> | Hixie, sounds perfect |
| 21:31 | <mcarter> | I just want to provide the feeling that I didn't make this WebSocket up all by myself |
| 21:32 | <Hixie> | hehe |
| 21:33 | <Hixie> | usually people have the opposite problem :-P |
| 21:35 | <zcorpan_> | hsivonen: i'll figure out if validator.nu is compatible with windows or not, i guess :) |
| 21:35 | <zcorpan_> | wonder if i have JDK 5 |
| 21:37 | <hsivonen> | zcorpan_: cool |
| 21:37 | <hsivonen> | zcorpan_: build.py expects to be able to create symlinks |
| 21:37 | <hsivonen> | zcorpan_: the potentially Windows-incompatible spots in build.py should have comments to that effect |
| 21:38 | <jcranmer> | zcorpan_: that's an ancient version! |
| 21:38 | <jcranmer> | you should be using JDK 6, if not milestone builds of Java 7! |
| 21:38 | <hsivonen> | jcranmer: Validator.nu doesn't require later than that |
| 21:38 | <hsivonen> | later than 5 that is |
| 21:38 | jcranmer | takes that to mean that it actually uses Java 5's features |
| 21:38 | <hsivonen> | yes |
| 21:39 | <hsivonen> | generics and StringBuilder mainly |
| 21:39 | <jcranmer> | no enums? not that it's really important |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/list.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/meta.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/nameident.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/object.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/param.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/pres.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/script.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/ssismap.rng |
| 21:40 | <hsivonen> | jcranmer: yeah, enums too for perf-insensitive enums |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/struct.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/style.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/table.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/target.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/modules/text.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/xhtml-basic.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/xhtml-strict.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/xhtml.rng |
| 21:40 | <zcorpan_> | http://www.thaiopensource.com/relaxng/xhtml/xhtml11.rng |
| 21:40 | <zcorpan_> | http://www.w3.org/2001/XMLSchema.dtd |
| 21:40 | <zcorpan_> | http://www.w3.org/2001/datatypes.dtd |
| 21:40 | <zcorpan_> | http://www.w3.org/Graphics/SVG/1.1/rng/svg-basic-structure.rng |
| 21:41 | <Hixie> | heh |
| 21:41 | <Hixie> | mispaste i assume :-) |
| 21:41 | <jcranmer> | most likely |
| 21:41 | <zcorpan_> | oops |
| 21:41 | <zcorpan_> | sorry |
| 21:41 | <Hixie> | no worries |
| 21:41 | <zcorpan_> | IOError: [Errno 2] No such file or directory: './onvdl/saxon/dist/saxon-whattf.jar' |
| 21:41 | <zcorpan_> | right after fsrc = open(src, 'rb') |
| 21:42 | <hsivonen> | zcorpan_: chances are that Saxon failed to build earlier |
| 21:42 | <Hixie> | though if someone was gonna try to spam the channel, schema URIs do seem like a good choice! |
| 21:42 | <zcorpan_> | Hixie: :) |
| 21:44 | <zcorpan_> | hsivonen: because i didn't have JDK? |
| 21:46 | <hsivonen> | zcorpan_: did it print messages looking like javac output? |
| 21:46 | <hsivonen> | if you have javac and jar in PATH, it should print all kinds of cruft when javac runs |
| 21:46 | <zcorpan_> | 'javac' -nowarn -classpath './dependencies/commons-codec-1.3/commons-codec-1.3.j.... |
| 21:47 | <zcorpan_> | saxon/classes' @temp-javac-list |
| 21:47 | <hsivonen> | that's the echo of the javac invocation |
| 21:47 | <zcorpan_> | sh: javac: command not found |
| 21:47 | <hsivonen> | well that's the problem then |
| 21:48 | <hsivonen> | build.py has command line options for specifying path to javac if it isn't autodiscovered |
| 21:48 | <hsivonen> | see --help |
| 21:50 | <zcorpan_> | ok |
| 21:52 | <hsivonen> | bed time on my timezone |
| 21:52 | <hsivonen> | nn |
| 21:52 | <zcorpan_> | nn |
| 21:58 | zcorpan_ | builds again, this time *with* JDK... |
| 22:05 | <zcorpan_> | well it still didn't work but for other reasons |
| 22:08 | <jgraham__> | gsnedders: You have modified my outline.py to match the current spec? |
| 22:09 | <gsnedders> | jgraham__: Yeah, it was mainly just ripping out your algorithm. It's really not much. I deleted my own local copy anyway. |
| 22:09 | <jgraham__> | So I have to be bothered to do it myself? |
| 22:10 | <jgraham__> | i.e. you can't just put the file somewhere? |
| 22:12 | <gsnedders> | jgraham__: I deleted it, as I said |
| 22:16 | <Hixie> | gsnedders: so the outline algorithm is all set now right? |
| 22:16 | <gsnedders> | Hixie: Yeah. I think it could be clearer in how it is written, but it works |
| 22:17 | <Hixie> | yeah well, hopefully diagrams and examples and intro text will help with that in due course |
| 22:17 | <Hixie> | getting the algorithm right is the first step :-) |
| 22:17 | <Hixie> | and it's much better than it was, right? |
| 22:17 | <gsnedders> | Yeah, sure. |
| 22:17 | <gsnedders> | Helping you avoiding to doing URLs has its uses :) |
| 22:19 | <Hixie> | :-) |
| 22:20 | <Hixie> | i really want to do done with this url crap and go on to WebSocket! |
| 22:20 | <Hixie> | bbiab |
| 22:28 | <Lachy> | woah, I haven't had a chance to look at the URL at all till just now. Hixie, assuming I'm looking at the right section (3.2.9) it doesn't look like you've done much at all with it. |
| 22:32 | <jcranmer> | Hixie: if it makes you feel better I get to break through encrusted layers of hacks... |
| 22:33 | <zcorpan_> | Lachy: it's mostly annotating the source with XXXURL comments, i think, so Hixie knows what needs doing |
| 22:37 | <Lachy> | ah, ok. |
| 22:38 | <Lachy> | oh, geez. Now I see why it's such a boring job. |
| 22:41 | <Philip`> | Many people spend their whole lives in boring jobs, so it's unreasonable to complain after only a few days of it :-p |
| 22:41 | <krijnh> | shepazu: Pong |
| 22:42 | <shepazu> | hey, krijnh, did you see this thread? http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0226.html |
| 22:43 | <krijnh> | I have now |
| 22:43 | <shepazu> | :) |
| 22:43 | <krijnh> | There is no [off] thing (yet) |
| 22:44 | <shepazu> | is it possible you could add an "[off]"? |
| 22:44 | <krijnh> | And yes, my connections sometimes drops :) |
| 22:44 | <krijnh> | Yeah, I think it is |
| 22:44 | <shepazu> | hey, I'm not complaining... but it would be nice if everything were perfect :) |
| 22:44 | <krijnh> | Everything will never be perfect, just accept that ;) |
| 22:44 | <shepazu> | [off] never! |
| 22:45 | <krijnh> | Which makes it perfect immediately |
| 22:45 | <krijnh> | Anyway, I have no idea how I can not log [off] messages |
| 22:45 | <shepazu> | just close my eyes and believe, eh? |
| 22:46 | <krijnh> | But I could hide them in the views |
| 22:46 | <Philip`> | Make the script read from `grep -v '> \[off\]' log.txt` instead of from log.txt? |
| 22:46 | <shepazu> | you mean more than CSS, right? :) |
| 22:46 | <krijnh> | They would still be in the logs |
| 22:46 | <krijnh> | PHP parses the logfiles, and wraps them in some HTML |
| 22:46 | <krijnh> | I could ignore the [off] lines |
| 22:46 | <Philip`> | Does anyone other than you have access to those raw logs? |
| 22:47 | <zcorpan_> | shepazu: the easy way to solve the connection drop problem is to have multiple independent loggers |
| 22:47 | <krijnh> | Not that I know of |
| 22:47 | <shepazu> | zcorpan_: yup |
| 22:47 | <zcorpan_> | shepazu: what's the point in making [off] lines not go in the logs? |
| 22:47 | <Philip`> | zcorpan_: That doesn't help if there's a netsplit and all the loggers are stuck on the opposite side to the discussion |
| 22:47 | <hober> | zcorpan_: feedback from #webapps |
| 22:48 | <shepazu> | zcorpan_: some people don't like being logged... |
| 22:48 | <hober> | zcorpan_: doug wants the feature, though I don't know who would use it |
| 22:48 | <krijnh> | Is it okay if [off] lines are presented as "[off]" ? |
| 22:48 | <krijnh> | It could be weird if in the middle of a discussion some lines are missing |
| 22:48 | <hober> | Personally, I think there should be some indication on the site if lines were redacted |
| 22:48 | <krijnh> | I agree |
| 22:48 | <shepazu> | yeah, I agree |
| 22:49 | <krijnh> | Oki |
| 22:49 | <shepazu> | cool, thanks! |
| 22:49 | <hober> | In fact, I'd like it to have the nick of the relevant party. |
| 22:49 | <hober> | So you can tell *that* so-and-so said something, but not *what* |
| 22:49 | <krijnh> | Indeed |
| 22:49 | <shepazu> | hober: you're getting into the bounds of crossing the privacy line |
| 22:49 | <krijnh> | Do you guys need some sort of consensus on that? :) |
| 22:49 | <hober> | I dunno. It's a public WG |
| 22:50 | <hober> | I think wanting your IRC to not be logged is somewhat antisocial |
| 22:50 | <krijnh> | So not web 2.0 |
| 22:50 | <hober> | and I'd like such antisocial behavior exposed if we're going to cater to it with some kind of feature |
| 22:50 | <Philip`> | You could always have an additional secret channel, like we have with #whatwg-cabal |
| 22:50 | <zcorpan_> | if someone doesn't want something to be logged, don't say it in a logged channel |
| 22:50 | <shepazu> | hober: while other think that people logging their every comment is antisocial :) |
| 22:50 | <zcorpan_> | i honestly don't see the problem |
| 22:50 | <hober> | zcorpan_: right |
| 22:50 | <krijnh> | Philip`: I'm logging that as well, under a different nick ;) |
| 22:51 | <shepazu> | zcorpan_: if you don't see the problem, then you aren't the person who wants this feature :) |
| 22:52 | <shepazu> | nor am I, usually... though on channels where we have the feature, it's been used a lot |
| 22:52 | <Philip`> | "it's been used a lot" could be considered an argument against it |
| 22:52 | <zcorpan_> | so what if someone in the channel logs and publishes without hiding [off] lines? |
| 22:52 | <Lachy> | I would prefer that everything was logged and people were just careful with what they said |
| 22:52 | <shepazu> | krijnh: I would be against logging someone's comment at all, even their nick, if they used [off] |
| 22:53 | <shepazu> | zcorpan_: then that's really rude |
| 22:53 | <Lachy> | shepazu, how does RRSAgent handle [off] lines in the logs? |
| 22:53 | <krijnh> | shepazu: you mean against saving it in some static file? |
| 22:54 | <shepazu> | krijnh: well, at the very least, against making it public |
| 22:54 | <krijnh> | I think it's pretty confusing if some lines are missing inside a discussion, without any notion of that fact |
| 22:54 | <krijnh> | For people reading afterwards |
| 22:54 | <shepazu> | just because I'm having a conversation on my mobile phone in public doesn't mean I want someone to record it and broadcast it on the radio |
| 22:55 | <krijnh> | Eh, okay |
| 22:55 | <shepazu> | krijnh: then just put all redacted lines as "[off]" |
| 22:55 | <hober> | krijnh: agreed. there needs to be some indication that (someone|nick) said something that they didn't want logged. |
| 22:55 | <shepazu> | including the nick |
| 22:55 | <krijnh> | I replied 'Oki' to that :) |
| 22:56 | <shepazu> | yeah, but then other people went on from there |
| 22:56 | <shepazu> | just making it clear :) |
| 22:56 | <zcorpan_> | shepazu: if you call a radio station when they're on air then you know it'll be broadcasted on the radio. would you want an [off] feature in that case so you can say things without getting it broadcasted? |
| 22:56 | <krijnh> | That's just the WHATWG cabal, ignore them |
| 22:56 | <krijnh> | *runs* |
| 22:56 | <krijnh> | zcorpan_: that's more what this is, indeed |
| 22:57 | <shepazu> | zcorpan_: I'm not going to debate privacy issues with you :) if you don't want privacy, awesome... but don't impose your prefernce on everyone else |
| 22:57 | <zcorpan_> | i want privacy, but not in irc channels :) |
| 22:58 | <Lachy> | shepazu, if people want privacy, the easy option is to take the discussion out of the public channel |
| 22:58 | <zcorpan_> | that are publically logged |
| 22:58 | <Philip`> | It's more like a Reality TV show, where you have discussions that are intended to just be between you and the people you're talking to, but you know there's the possibility that loads of other people will be looking in on what you're doing |
| 22:58 | <shepazu> | Lachy: RRSAgent doesn't honor "[off]" (I think), but it doesn't log lines starting with "/me" |
| 22:58 | <Lachy> | but I think for a public WG, that's not something that should happen often when discussing WG related stuff |
| 22:58 | <hober> | Lachy: exactly |
| 22:58 | <Lachy> | shepazu, I think the fact that RRSAgent doesn't log /me lines is an annoying bug. |
| 22:58 | Philip` | [off] wonders if this will hide the line from everyone |
| 22:59 | <zcorpan_> | Lachy: agreed |
| 22:59 | <shepazu> | Lachy: me too |
| 22:59 | <shepazu> | cool, guys, if you don't want to use "[off]", then don't |
| 22:59 | <krijnh> | Philip`: come again? |
| 22:59 | <anne-olpc> | fwiw, I think it would be better if [off] was logged; don't say things you don't want logged in a public channel |
| 22:59 | krijnh | is confused |
| 23:00 | <anne-olpc> | (as in, not kept out of the logs) |
| 23:00 | <Philip`> | krijnh: If "/me ..." hides from RRSAgent, and "[off] ..." hides from your logs, I was wondering if "/me [off] ..." would work for both |
| 23:00 | <krijnh> | What would be a good use case for [off] anyway? |
| 23:00 | anne-olpc | might have missed the last minute on this discussion, sorry |
| 23:00 | <gsnedders> | I think anne-olpc is right: don't say things you don't want logged in the channel. |
| 23:00 | <shepazu> | anne-olpc: check the logs :) |
| 23:00 | <krijnh> | anne-olpc: see the logs ;) |
| 23:01 | <krijnh> | What kind of statements would you put in [off] btw? |
| 23:01 | <anne-olpc> | perf and keyboard are not too great on the OLPC |
| 23:01 | <anne-olpc> | Opera helps, but still |
| 23:01 | <krijnh> | [off] Opera sucks, btw |
| 23:02 | <Lachy> | krijnh, insults, mostly ;-) |
| 23:02 | <krijnh> | Opera rules! |
| 23:02 | <krijnh> | [off] My previous line was a lie, hrhr |
| 23:02 | <zcorpan_> | krijnh: can't reveal what [off]'d be used for in public of course |
| 23:02 | <shepazu> | cursing, jokes, private info like email addresses or sikkrit URLs |
| 23:02 | <gsnedders> | [off] f off, Lachy! |
| 23:02 | <krijnh> | Email: that's a good one |
| 23:02 | <hober> | It makes me happy that /me's in #html-wg show up in krijnh's logs |
| 23:03 | <smedero> | that's the only one in the list that caught my attention.... email harvesting. |
| 23:03 | gsnedders | is happy too |
| 23:03 | <Philip`> | "[off]" sounds like useful metadata that indicates interesting and/or juicy lines |
| 23:03 | <Philip`> | You should extract them all and publish them anonymously |
| 23:03 | <shepazu> | for money |
| 23:03 | jcranmer | seconds Philip` 's idea |
| 23:03 | <gsnedders> | [off] The truth is, I'm gay. |
| 23:03 | <Lachy> | if people who post to the W3C WG mailing lists are worried about email harvesting, I have news for them! |
| 23:03 | <krijnh> | smedero: that would be solved by a regex (yeah yeah, I know they suck for URIs) changing it to some obfuscated string |
| 23:04 | <Philip`> | Reading through complete IRC logs is normally really boring, so it's good to highlight to private and controversial bits |
| 23:04 | <shepazu> | Lachy: anyone who posts to w3c mailing lists signs a waiver |
| 23:04 | <Lachy> | and since most, if not all people in #webapps would, it's not a problem worth worrying about in the IRC channel |
| 23:04 | <anne-olpc> | exchanging sensitive info is what /msg is for |
| 23:04 | <krijnh> | gsnedders: note to you gayman, [off] lines are still logged |
| 23:04 | <smedero> | right. |
| 23:04 | <gsnedders> | krijnh: I know :) |
| 23:04 | <jcranmer> | note to self: start a spambot who uses [off] lines |
| 23:04 | <krijnh> | gsnedders: I know you know :) |
| 23:04 | <Lachy> | shepazu, yeah, I know. I was just pointing out the futility of protecting email addresses in here, while they're all public in the list archive |
| 23:05 | <gsnedders> | krijnh: I know everything, but you don't know that. |
| 23:05 | <Philip`> | anne-olpc: /msg isn't for sensitive information - "Note: this server is INSECURE; you should assume that anyone could be listening to anything you say here." |
| 23:05 | <krijnh> | gsnedders: just go do your outlining thing ;p |
| 23:05 | <gsnedders> | krijnh: Done, now :P |
| 23:05 | <anne-olpc> | as far the thing about krijnh being offline, the W3C should start competing! |
| 23:05 | <krijnh> | Really? |
| 23:05 | <anne-olpc> | that'd be great |
| 23:05 | <gsnedders> | krijnh: There were basically two bugs: one in the spec, one in the impl (because the spec was unclear) |
| 23:05 | <krijnh> | Ah okay |
| 23:06 | <shepazu> | anne-olpc: they plan to, iirc, but they are still setting up the bot to do it |
| 23:06 | <gsnedders> | krijnh: There's nothing yet to actually properly build it up into a TOC, though |
| 23:06 | <krijnh> | anne-olpc: should I introduce new features then as well? |
| 23:06 | <anne-olpc> | or the W3C could offer krijnh a more stable server or something |
| 23:06 | <anne-olpc> | krijnh: |
| 23:06 | <krijnh> | :D |
| 23:06 | <anne-olpc> | krijnh, sure, when needed :) |
| 23:07 | <krijnh> | I've introduced 30 subtitles this morning already ;) |
| 23:07 | <gsnedders> | krijnh: http://pastebin.com/mcdbe30b — that's a magic outline! |
| 23:07 | <krijnh> | That's enough for a while |
| 23:07 | <shepazu> | there are a lot of people (some team, some members) who are concerned about the privacy implications of logging at all, so I think this is a good compromise |
| 23:07 | <anne-olpc> | krijnh, yaeh, hehe |
| 23:07 | <Hixie> | these people realise that webapps is a public wg right? |
| 23:07 | <anne-olpc> | dude, typing sux0rs |
| 23:08 | <krijnh> | anne-olpc: you're not a child anymore, so in some way it makes sense an olpc sucks for you |
| 23:08 | <anne-olpc> | plastic buttons designed for people with small hands |
| 23:08 | <krijnh> | ^^ |
| 23:08 | <shepazu> | anne-olpc: the keyboard is made for little kids, and you're like 8 feet tall |
| 23:08 | <anne-olpc> | uhuh |
| 23:08 | <Philip`> | Outline of the HTML5 spec: .--. | | '--' |
| 23:08 | <anne-olpc> | but it's nice :) |
| 23:08 | <Philip`> | Oh wait, that didn't work |
| 23:08 | <Philip`> | .--. |
| 23:08 | <Philip`> | | | |
| 23:08 | <Philip`> | '--' |
| 23:08 | <Hixie> | Philip`: hah |
| 23:08 | <Philip`> | There you go |
| 23:08 | <krijnh> | So, bottom line, do I want to go down the [off] route thingy? |
| 23:08 | <shepazu> | yeah, it's a cute lil machine |
| 23:08 | <Hixie> | your ratio is way off |
| 23:08 | Philip` | wonders why irssi eats newlines |
| 23:09 | <Hixie> | it's like a 1000 page document by now |
| 23:09 | <Philip`> | Hixie: How about: |
| 23:09 | <Philip`> | | |
| 23:09 | <Hixie> | hah |
| 23:09 | <Hixie> | yeah |
| 23:09 | <Philip`> | assuming you have a very narrow font |
| 23:09 | <Hixie> | that's more like it :-) |
| 23:09 | <Hixie> | even a wider font |
| 23:09 | <anne-olpc> | krijnh, nope? |
| 23:09 | <gsnedders> | Nah, more like: |
| 23:09 | <gsnedders> | | |
| 23:09 | <gsnedders> | | |
| 23:09 | <Hixie> | krijnh: if you do, please make sure it doesn't work in #whatwg :-) |
| 23:09 | <shepazu> | krijnh: please, yes |
| 23:10 | <krijnh> | Bidding starts at $50 |
| 23:10 | <shepazu> | if only on channels that request it |
| 23:10 | anne-olpc | bids against :) |
| 23:10 | <zcorpan_> | let's vote! :-p |
| 23:10 | <krijnh> | shepazu: I'll fix it for #webapps |
| 23:11 | <anne-olpc> | anyways, already said why it's a bad idea |
| 23:11 | <shepazu> | krijnh: thanks |
| 23:11 | <shepazu> | oops.. |
| 23:11 | <shepazu> | [off] krijnh, thanks for furthering the cause of the privacy cabal |
| 23:11 | <Hixie> | anne: it's a terrible idea, but it makes perfect sense that the w3c would ask for it :-) |
| 23:11 | <krijnh> | shepazu: Although, having some experience in creating buggy stuff, I don't want to commit myself to this too much |
| 23:12 | <hober> | I find it worrisome, given that the wg is public |
| 23:12 | <shepazu> | heh |
| 23:12 | <Philip`> | krijnh: Opera 9.5 interacts badly with your log site |
| 23:12 | <anne-olpc> | Hixie, :/ |
| 23:12 | <krijnh> | [off] Philip`: Opera sucks |
| 23:12 | <anne-olpc> | Hixie, some of the stuff recently... |
| 23:12 | <krijnh> | Ow, shit, it doesn't work in here :p |
| 23:12 | <Philip`> | krijnh: Its address bar tends to remember the address when I just type 'k', whereas Opera 9.2 was rubbisher and I had to keep typing in krijnhoetmer.nl and therefore learnt how to spell your name |
| 23:13 | <anne-olpc> | my OLPC says it's 17:14, but I think I'll go to bed |
| 23:13 | <anne-olpc> | nn |
| 23:13 | <krijnh> | :w |
| 23:13 | <tndH> | why not have a user option on the logs site? [ ] show secret conversations :D |
| 23:13 | <krijnh> | Philip`: I don't really see what you mean |
| 23:13 | <Philip`> | tndH: That can be a premium registration feature |
| 23:13 | <krijnh> | Pro accounts, tee hee |
| 23:13 | <shepazu> | nn, lil anne |
| 23:14 | zcorpan_ | should go to bed as well |
| 23:14 | <Hixie> | i wonder if we should ask for an [off] feature for the wg mailing list archives as well |
| 23:14 | Philip` | estimates he will go to bed in four hours, and then wake up an hour late tomorrow and get into work two hours late |
| 23:15 | <krijnh> | Hixie: that doesn't involve extra work for me, so I'm okay with that :) |
| 23:15 | <shepazu> | Hixie: people already sign a waiver there, so it's a false analogy |
| 23:16 | <Hixie> | hmm, maybe a better solution then is to make them sign a waiver for irc :-) |
| 23:16 | smedero | supposes he'll go streaking through the public square with an [off] banner covering his twig and berries |
| 23:16 | <shepazu> | yep, that's a thought |
| 23:16 | <shepazu> | um, Hixie's thought, not smedero's :) |
| 23:16 | <smedero> | :) |
| 23:17 | <smedero> | now I suppose you want retroactive [off] too? :) |
| 23:17 | <shepazu> | no, I'll use my what-ifs for much more important things |
| 23:18 | <smedero> | haha, fair enough |
| 23:19 | <smedero> | maybe when our IRC nodes implement Dmitry Turin's IRC6 protocol the world will be a better place. |
| 23:19 | <krijnh> | Testint, testing |
| 23:19 | <krijnh> | [ow-damn-previous-line-should-be-off] |
| 23:19 | <krijnh> | That's my new feature when the W3C is going to compete with my logs ^ |
| 23:20 | <Philip`> | http://futureoftheinternet.org/blog/ - Opera 9.5 puts the bottom half of the page in a <code> font, because there's a "<p>...<code></p>" - Opera really needs to use the HTML5 parsing algorithm :-) |
| 23:22 | <Hixie> | yes |
| 23:22 | <Hixie> | yes it does |
| 23:22 | <Philip`> | Also, good job blurring out the email address in the Passport screenshot |
| 23:23 | <Hixie> | krijnh: i wouldn't worry too much about the w3c competing with you... experience with html5 suggests that they are easy to compete with :-P |
| 23:23 | <krijnh> | lol |
| 23:23 | <krijnh> | Yeah well |
| 23:23 | <krijnh> | Depends on who's competing ;) |
| 23:23 | <krijnh> | Err, on who they're competing with |
| 23:23 | <Hixie> | the first step seems to be "Do something" |
| 23:24 | <krijnh> | Yeah, I'm busy, relax :) |
| 23:24 | <Hixie> | after that, you're home dry |
| 23:25 | <Hixie> | actually that's probably not fair, the w3c does do things, even if very slowly |
| 23:25 | <Hixie> | they just tend to do the wrong thing |
| 23:25 | <krijnh> | http://krijnhoetmer.nl/irc-logs/webapps/20080619 |
| 23:25 | <Hixie> | you should make it white on black text :-) |
| 23:25 | <Hixie> | instead of italics |
| 23:26 | <shepazu> | yeah, Hixie is much faster about doing the wrong thing :) |
| 23:27 | <Philip`> | But none of us can beat Mozilla|Opera|Microsoft|Apple|etc at rapidly doing things wrong :-) |
| 23:29 | <roc> | we shipped 82 terabytes of wrongness yesterday and I'm pretty happy about that |
| 23:31 | <Philip`> | All we can do is write some words that will probably be ignored - there's no way to compete fairly :-( |
| 23:31 | <roc> | they won't be ignored |
| 23:31 | <roc> | this isn't 2001 |
| 23:31 | <Philip`> | Well, that depends on which specs we're writing :-) |
| 23:31 | <Philip`> | and who "we" is |
| 23:32 | <roc> | oh sorry, are you working on XHTML2? |
| 23:32 | <Philip`> | "We" could be inclusive of the people who are |
| 23:33 | <Philip`> | I should probably say "is" instead of "could be" because then it'd look like I understood what I was saying before I said it, instead of making it up as I'm going along |
| 23:34 | <Philip`> | Anyway, HTML5 does seem to be one of the most efficient specs for getting wrongness deployed, since browser developers seem to trust it, so that's okay |
| 23:40 | <othermaciej> | written wrongness has much less effect than wrongness shipped in software, regardless of number of copies distributed |
| 23:59 | <Philip`> | Have I already mentioned that I don't like it when the spec has identical paragraphs with different meanings? |