| 00:02 | <Hixie> | i'll let y'all handle that one :-) |
| 00:02 | <Dashiva> | It seems to me that MoinMoin can't generate <th> in tables |
| 00:02 | <Dashiva> | How's that for accessibility... |
| 00:04 | <Philip`> | <td colspan="3" style="text-align: center"><p class="line891"><strong>Heading</strong></td> |
| 00:04 | <Philip`> | (via http://moinmoin.wikiwikiweb.de/HelpOnTables ) |
| 00:04 | <Dashiva> | Ayup |
| 00:06 | <Philip`> | The wiki-code for tables looks fairly ugly - does anybody have a nice way of marking up tables? |
| 00:09 | Philip` | kind of likes the LaTeX syntax, since you normally only need a single line of setup code and then every row is like "cell1 & cell2 & cell3 \\" which is about as minimal as possible |
| 00:09 | <Dashiva> | Mediawiki's way is bad because it clashes with template syntax, but just markup-wise it covers most of it |
| 00:09 | <Philip`> | (http://en.wikibooks.org/wiki/LaTeX/Tables etc) |
| 00:10 | <Dashiva> | (You can't do the fancy stuff like col/colgroup/thead etc, but they allow plain html for the complex stuff) |
| 00:11 | <Philip`> | (Does that mean you can write a simple table with the wiki syntax, then add a few more complex features, but once you get to a certain point and want another feature you have to rewrite the entire thing into HTML?) |
| 00:12 | <Dashiva> | No, you can just copypaste the output of the old code :) |
| 00:12 | <Lachy> | Hixie, you might be able to answer this more better than I can. http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx#8422881 |
| 00:12 | <Philip`> | Dashiva: What if you want to remove that final feature and convert it back to the wiki syntax? :-) |
| 00:12 | <Dashiva> | Run a regexp on it :) |
| 00:12 | <Lachy> | s/more better/better/ |
| 00:13 | <Dashiva> | You could even write a wikicode serializer and link it to html5lib! |
| 00:15 | <Hixie> | Lachy: commented |
| 00:21 | Philip` | wonders if it's possible/sensible for a script to override document.write and intercept all the written strings |
| 00:22 | <Philip`> | (I'd like to let pages get proper HTML5 parsing by adding a line <!doctype html><script src=html5parser.js></script> to the top, but that seems like it'd be a bit messier if the page tries doing fancy scripting stuff itself) |
| 00:24 | <Lachy> | Hixie, there's a few more exceptions you forgot to mention, like always appending link and meta elements to the head, even if it's not open. |
| 00:24 | <Lachy> | though, I suppose that doesn't insepct the DOM to do that, it just maintains a separate head pointer |
| 00:48 | <mcarter> | hello |
| 00:49 | <mcarter> | othermaciej, I'm curious what your proposal is for an http based protocol for TCPConnection? |
| 00:49 | <mcarter> | othermaciej, Hixie mentioned that the protocol was your main objection |
| 00:49 | <othermaciej> | mcarter: I don't have a full proposal for how to satisfy the TCPConnection use cases |
| 00:50 | <mcarter> | othermaciej, Ok, I'm at least interested in the reasons for it |
| 00:50 | <othermaciej> | my two problems with it are: (1) it uses port/host addressing instead of URI addressing, which is a poor fit for the Web model |
| 00:50 | <mcarter> | othermaciej, I'm putting together a document about the pros and cons of http for TCPConnection |
| 00:50 | <othermaciej> | (2) it's bad to send non-http over the assigned ports for http and https |
| 00:51 | <othermaciej> | (3) I am worried that connection to arbitrary ports could lead to security issues, although Hixie tried hard to avoid them |
| 00:51 | <othermaciej> | (basically the only security mechanism though is assuming that no other protocol will happen to emulate the TCPConnection handshake, which seems pretty weak) |
| 00:52 | <othermaciej> | (given that other protocols have been found to have multiple interpretation vulnerabilities) |
| 00:52 | <othermaciej> | I guess that is three problems |
| 00:52 | <mcarter> | ok |
| 00:52 | <mcarter> | i had a couple of other concerns |
| 00:52 | <mcarter> | With SSL there is no way to do virtual hosting -- you have to route on ip address... HTTP/1.1 upgrade with TLS solves this problem |
| 00:53 | <othermaciej> | mcarter: I think a custom http method that begins a two-way session might be a promising solution, but I think that would require a proof of concept that it is viable on client and server side |
| 00:53 | <mcarter> | Http provides the Host header to avoid dns rebinding attacks |
| 00:53 | <mcarter> | othermaciej, it seems to me the way to do it is send an OPTIONS with an Upgrade: tcp/1.0 header as the client->server tcp handshake |
| 00:53 | <othermaciej> | mcarter: those are also good points |
| 00:54 | <mcarter> | also, HTTP based connections include query parameters and cookies, allowing for normal auth mechanisms |
| 00:55 | <mcarter> | othermaciej, i'll add your three points to my document |
| 00:56 | <mcarter> | the big hurdle is keeping it simple enough for Hixie's requirements, particularly that it be possible to implement in just a few lines of perl |
| 00:56 | <Philip`> | use Net::HTML5::Connection; |
| 00:56 | <Philip`> | run_server(); |
| 00:57 | <Philip`> | Should it be a few lines of Perl that a normal Perl programmer would write, or a few lines that a Perl golfer could write? |
| 00:57 | <mcarter> | Philip`, he wants it to be 3 lines with no support libraries |
| 00:59 | <Hixie> | i dunno about 3 |
| 01:00 | <Hixie> | i think i said a few dozen |
| 01:00 | <Hixie> | but the point is it has to be a fully compliant implementation |
| 01:00 | <Philip`> | Is there any problem that can't be solved in a few dozen lines of Perl? |
| 01:01 | <takkaria> | the travelling salesman problem? |
| 01:02 | <Philip`> | takkaria: That's a trivial problem to solve - just enumerate all possibilities and pick the best |
| 01:03 | <takkaria> | quickly, then. :) |
| 01:03 | <Philip`> | It's trivial to do it quickly, at least for certain input sizes :-) |
| 01:05 | <takkaria> | OK, I'll stop defending my quick and ill-thought-out reponse now |
| 01:05 | <takkaria> | anyone else want a go? :) |
| 01:12 | <Philip`> | perl -lpe'@==sort@p=map$_.shift@=,@@for@@=/,|\pL/g;$_=@p[$`]' |
| 01:12 | <Philip`> | Apparently that does the Burrows-Wheeler transform, but I don't quite see how :-/ |
| 01:14 | <jwalden> | Hixie: in 6.4.1, you can't check the origin of the target document while postMessage is running -- what happens if the target window is navigated to another location before the event is dispatched? |
| 01:18 | <jwalden> | as far as I can tell, the only thing you can/must do at postMessage time is determine the origin of the caller; everything else must happen immediately before the event is dispatched |
| 01:19 | <mcarter> | Hixie, oh, i think we could get it done in just a few lines of code even if it was http-based |
| 01:21 | <mcarter> | Hixie, i don't think saying "it should be implementable in 3-10 lines of perl" is unreasonable whatsoever |
| 01:26 | <othermaciej> | mcarter: my vague idea was to repurpose the CONNECT method, since that is likely to already work through proxies |
| 01:27 | <othermaciej> | mcarter: but developing the proper server-side support would be tricky |
| 01:27 | <othermaciej> | so I feel like it is not worth suggesting without proof-of-concept client and server impls |
| 01:27 | <othermaciej> | I think the two-way persistent connection problem may just have to get solved after HTML5 |
| 01:29 | <mcarter> | othermaciej, well, I'm working on a proof of concept so feel free to suggest to me any ideas you have |
| 01:39 | <mcarter_> | othermaciej, i lost connectivity there, but i had try to say that you should give me any ideas/suggestions you have for bi-directional communication protocols because I'm making a proof of concept client and server |
| 02:11 | <othermaciej> | mcarter: ok, so my idea was to overload CONNECT, have an apache module that lets a CGI script or similar handle this, and have it establish a two-way TCP connection |
| 02:11 | <othermaciej> | mcarter: using "upgrade" also seems like an interesting idea though may be less proxy-compatible |
| 02:11 | <Philip`> | Apache module sounds scary |
| 02:12 | <othermaciej> | I have no idea how hard or easy it is to write an Apache module but I assume it is easier than an IIS plugin |
| 02:12 | <Philip`> | Apache modules don't work too well in lighttpd either :-( |
| 02:13 | <othermaciej> | I'm not sure there is a viable solution that will work with every existing httpd |
| 02:13 | <othermaciej> | (Hixie's approach was basically to run services that don't hook into httpd at all on totally separate ports) |
| 02:15 | <Philip`> | I'm not sure what problem this is trying to solve, so I suppose I should find that out first |
| 02:16 | <othermaciej> | the problem is enabling full duplex messaging between a client and a server over a single established TCP connection (to avoid overhead of constantly creating and destroying connections) |
| 02:16 | <Philip`> | Server-sent events + XHR with HTTP pipelining? |
| 02:16 | <othermaciej> | the closest thing to it over http is http pipelining combined with a multipart (or otherwise incremental) http response |
| 02:17 | <Philip`> | (or just keepalive) |
| 02:17 | <Hixie> | my main use case was on a machine that didn't even have a web server |
| 02:17 | <Hixie> | but that's another story |
| 02:17 | <Hixie> | jwalden: woops, good point |
| 02:17 | <Hixie> | jwalden: fix on the way |
| 02:18 | <othermaciej> | XHR with pipelining might be viable, but there's no solution on the server side (afaik) to bind a pipeline to a single process which handles all requests on it |
| 02:18 | <othermaciej> | so if you have a front-end server that farms out requests to individual process/threads to serve them, you have not really solved the use case |
| 02:19 | <othermaciej> | also http pipelining is currently not viable on the client side |
| 02:19 | <Philip`> | I'm pretty sure Opera did XHR pipelining when I last tested it |
| 02:19 | <othermaciej> | Opera tries to use super clever heuristics to figure out when it can avoid any of the servers or proxies that create problems |
| 02:19 | <Philip`> | Ah |
| 02:20 | <Philip`> | That sounds interoperable |
| 02:20 | <othermaciej> | but I don't think anyone else has enough faith in their ability to come up with sufficiently clever heuristics |
| 02:21 | <Philip`> | Aren't the servers and proxies likely to cause just as many problems for a brand new persistent-two-way-connection-over-HTTP thing than for pipelining? |
| 02:21 | <othermaciej> | an http pipeline does also impose quite a bit of protocol-level overhead if your messages are small, though maybe that doesn't matter in practice |
| 02:21 | <mcarter> | othermaciej, i don't think the Uprade header has anything to do with proxies. We'll still need to put send a CONNECT to the proxy no matter what protocol we choose |
| 02:21 | <othermaciej> | Philip`: the problem with pipelining is that some servers (and proxies) will scramble multiple responses when you give them pipelined requests |
| 02:21 | <mcarter> | also, I don't like http pipe-lining at all -- the only way to restart a stream is to close the actual tcp connection, or send http responses back to all the "acks" that have built up |
| 02:22 | <othermaciej> | Philip`: however, CONNECT does give you a way to tunnel a connection over the proxy at least for SSL that seems to work |
| 02:22 | <mcarter> | othermaciej, with the apache stuff, i don't think the topic is how someone should implement tcp connection, rather what protocol should be used |
| 02:23 | <mcarter> | othermaciej, later on, apache or anyone else can go ahead and implement whatever api/interaction with their current stuff that they want |
| 02:24 | <mcarter> | Philip`, server sent events + XHR, without pipelining provides a pretty workable duplex stream, but its really hard to implement |
| 02:24 | <Philip`> | Is this feature meant to work for people with very restricted networks that allow nothing except HTTP (maybe HTTPS) connections and only to their proxy server? |
| 02:25 | <Philip`> | mcarter: Ah, I suppose the pipelining doesn't actually matter except for latency |
| 02:25 | <Philip`> | (but I was looking at this in the context of a multiplayer FPS, where latency is pretty important) |
| 02:26 | <mcarter> | Philip`, yeah, for upstream latency you'd have to do somethign with multipart to make it reasonable |
| 02:27 | Philip` | wonders which direction is upstream |
| 02:27 | <mcarter> | good point. From a client/server point of view, upstream counts as towards the server, at least thats how I use the term |
| 02:27 | <Philip`> | Okay |
| 02:27 | <mcarter> | Philip`, a full duplex mechanism for the browser should work over restricted networks where traffic must pass through firewalls and/or http forward proxies |
| 02:28 | <mcarter> | Philip`, so we'll definitely need to send a CONNECT to the forward proxy either way |
| 02:28 | <Philip`> | Are there proxies that block everything except GET and POST? |
| 02:28 | Philip` | doesn't know how much effort people put into making their networks useless |
| 02:29 | <mcarter> | possibly, but they still support CONNECT for https |
| 02:29 | <mcarter> | CONNECT to a proxy basically means, "now ignore any more bytes that go up or down this connection" |
| 02:30 | <Philip`> | That sounds like a good feature to lock down when all your annoying users are trying to Skype through your network |
| 02:30 | <othermaciej> | mcarter: one requirement that Hixie (rightly) states is that this new approach must be reasonably easy to deploy on the server side |
| 02:31 | <othermaciej> | mcarter: I haven't proposed a protocol in part because I feel like I would need to prove it is viable with code |
| 02:31 | <othermaciej> | just making a protocol proposal isn't very helpful in itself |
| 02:31 | <mcarter> | othermaciej, this is precisely what i'm working on |
| 02:31 | <mcarter> | othermaciej, i'm making an implementation of the TCPConnection api in the browser that speaks to a special server that understands sse and xhrs as being upstream and downstream |
| 02:32 | <mcarter> | othermaciej, then that server opens a raw socket connection to the destination, and speaks the appropriate protocol |
| 02:32 | <mcarter> | othermaciej, so any browser code can use the javascript api, and the server code can just be a socket server that implements whatever the protocol is supposed to be |
| 02:32 | <mcarter> | othermaciej, so I'm interested in feedback as I put together a few example server implementations of that protocol |
| 02:33 | <othermaciej> | mcarter: I don't see the point of that |
| 02:33 | <othermaciej> | mcarter: it doesn't do anything to show viability of directly integrating support for the protocol into an existing server infrastructure |
| 02:33 | <mcarter> | one of the demos could easily be an apache module, if thats what you think it would take to prove anything |
| 02:34 | <mcarter> | personally, i'm more with hixie that it should be a few lines of perl |
| 02:34 | <othermaciej> | well, it's certainly not the only way |
| 02:34 | <othermaciej> | a few lines of perl almost certainly can't be a specific URI on the same host and port your document came from |
| 02:34 | <othermaciej> | anything where you have to pick a custom host and port can't work purely within the same-origin security model |
| 02:35 | <mcarter> | othermaciej, i believe the plan is to allow at least cross-sub-domain and probably fully cross-domain tcp connections |
| 02:35 | <Hixie> | yeah |
| 02:35 | <othermaciej> | yes, that is what TCPConnection allows, and one of the things I dislike about it |
| 02:35 | <Hixie> | oh? |
| 02:36 | <jwalden> | hm, this making the argument thing isn't so non-trivial if you actually decide to be principled and determine what the argument *should* be if it's provided and not "*" |
| 02:36 | <othermaciej> | the only security measure is assuming no other current or future network service can emulate the handshake |
| 02:36 | <mcarter> | othermaciej, it doesn't really make sense to just come up with some special protocol to speak to http servers. As I see it, TCPConnection to *other* services/daemons will enable a whole class of applications |
| 02:36 | <jwalden> | s/thing/non-optional thing/ |
| 02:36 | <othermaciej> | (or can be tricked into emulating the handhsake) |
| 02:36 | <othermaciej> | but TCPConnection can't talk to an arbitrary existing service |
| 02:36 | <othermaciej> | it has to talk to a custom service written for TCPConnection |
| 02:37 | <Hixie> | jwalden: you only need to include it in the reply, really, right? in which case just pass event.origin |
| 02:37 | <mcarter> | othermaciej, of course. but custom socket services are trivial to write, and give you the power of full duplex communication without banging your head against a wall or using flash |
| 02:37 | <jwalden> | Hixie: I have so many convolutions in most of these tests that it isn't always that simple |
| 02:37 | <Hixie> | jwalden: heh |
| 02:37 | <jwalden> | Hixie: further, providing the literal value is good defense anyway |
| 02:37 | <othermaciej> | it's like combining the worst parts of something http-based (can't talk to existing services) and something socket-based (no URI addressing, no same-origin security, no ability to leverage common http-based infrastrucutre) |
| 02:38 | <othermaciej> | that is the core of what is wrong with TCPConnection, in my mind |
| 02:38 | <Hixie> | jwalden: oh i agree |
| 02:38 | <Hixie> | jwalden: i expect there are two major use-cases |
| 02:38 | <othermaciej> | I want the full duplex functionality on a URI on my server |
| 02:38 | <jwalden> | so except in one or two cases where I'm using a single file generically, I have to determine what the exact value is |
| 02:38 | <othermaciej> | not a separate port on some other host |
| 02:38 | <Hixie> | jwalden: talking to a specific page on a specific host (in which case, it's known), and talking to anyone (in which case, it doesn't matter) |
| 02:38 | <othermaciej> | with no addressing of resources below host granularity |
| 02:38 | <mcarter> | othermaciej, I agree that the tcpconnection should be able to talk to your standard server. an integration with apache for instance |
| 02:38 | <Hixie> | jwalden: though i agree that often test cases end up being complicated for this kind of thing! |
| 02:39 | <mcarter> | othermaciej, but why not also let it talk to a custom service? |
| 02:39 | <othermaciej> | imagine I am logged into www.mychatservice.com |
| 02:39 | <othermaciej> | and the site wants to send my messages back and forth over a full duplex connection |
| 02:39 | <othermaciej> | if it's not over http to the same server, it can't rely on my cookies as the auth credential |
| 02:39 | <jwalden> | on the plus side, I've discovered a test I'd written earlier doesn't meaningfully test what it was testing any more since the domain/uri->origin change |
| 02:40 | <Hixie> | othermaciej: hm, we could send host and path information in the request |
| 02:40 | <jwalden> | I think I can use document.domain and some hacks to make it meaningful again |
| 02:40 | <mcarter> | othermaciej, thats exactly my earlier reason for why it should support cookies |
| 02:40 | <Hixie> | othermaciej: which would get us uri addressibility |
| 02:40 | <othermaciej> | what I'd like to do is open http://www.mychatservice.com/messagestream/othermaciej |
| 02:40 | <Hixie> | othermaciej: (in the same way that web servers do) |
| 02:40 | <othermaciej> | and have that be a two-way full duplex connection |
| 02:40 | <mcarter> | I see it like this, you should make a standard http request with a URL and headers, include an Upgrade: tcp/1.0 header |
| 02:40 | <othermaciej> | that follows the same-origin security model |
| 02:40 | <Hixie> | othermaciej: http is not a full-duplex protocol. we can never get this for an http://... uri |
| 02:40 | <mcarter> | the server can repond acknowledging the upgrade or not |
| 02:41 | <othermaciej> | and sends my cookies |
| 02:41 | <othermaciej> | Hixie: http supports on-the-fly conversion to other protocols (TLS upgrade) and custom methods that do whatever you want (which can tunnel through a proxy via CONNECT) |
| 02:42 | <Hixie> | othermaciej: in theory, sure |
| 02:42 | <mcarter> | Hixie, you can get this for an http:// uri though. just have an http handhsake with an upgrade header |
| 02:42 | <Hixie> | othermaciej: but i'm not writing an http server just so i can send messages back and forth |
| 02:42 | <othermaciej> | I don't know whether it is viable to do this in practice |
| 02:42 | <othermaciej> | that is why I think a proof of concept that integrates with a real server would be informative |
| 02:42 | <othermaciej> | Hixie: neither should you have to write an http server just so you can publish hypertext documents, but fortunately that problem has been solved for you |
| 02:43 | <Hixie> | the original use case i had for this -- my train server -- was a perl script about 50 lines long, most of which was infrastructure to talk to the machine's serial port to control my trains |
| 02:43 | <Hixie> | adding a compliant http server to this would be many more than 50 lines |
| 02:43 | <Hixie> | 1000 maybe |
| 02:43 | <mcarter> | Hixie, don't think of it like that. Choose a subset of http that an existing server would understand as http |
| 02:43 | <othermaciej> | I don't think a train server is a very interesting use case compared to things like chat or other notification streams |
| 02:43 | <Hixie> | mcarter: then it's not conforming |
| 02:44 | <Hixie> | mcarter: or it's not http |
| 02:44 | <mcarter> | Hixie, but thats okay |
| 02:44 | <mcarter> | Hixie, i'm saying, our protocol should NOT be http |
| 02:44 | <Hixie> | mcarter: what's the point of pretending to use http if it's not http? |
| 02:44 | <Hixie> | i'd still have to support http if you handshake on http first |
| 02:44 | <othermaciej> | writing an auth mechanism that works securely without leveraging the http-related infrastructure would take more than 50 lines too |
| 02:44 | <mcarter> | Hixie, so existing servers give back reasonable responses, and you can still do load balancing and authentication with existing methods |
| 02:44 | <mcarter> | Hixie, we handshake on a *subset* of http |
| 02:45 | <othermaciej> | most interesting two-way notification streams would require authentication and would be offered by web services that are already doing auth via http cookies |
| 02:45 | <Hixie> | mcarter: and what happens if someone steps outside that subset? it's still conforming http, so i still have to handle it somehow. |
| 02:45 | <mcarter> | Hixie, if the server steps out of our http-subset, then consider it an invalid tcp connection response and fire an onclose back |
| 02:46 | <Hixie> | mcarter: i don't consider that acceptable |
| 02:46 | <mcarter> | Hixie, the client won't step out because thats what we are trying to standardize. If it does, the server can just give back a 400 or something |
| 02:46 | <Hixie> | mcarter: either it's http or it isn't |
| 02:46 | <mcarter> | Hixie, why should it be one or the other though? |
| 02:46 | <Hixie> | mcarter: what if i connect to the server and do a HEAD request? or have a Host header that's wrong? or whatever |
| 02:47 | <Hixie> | mcarter: because profiling specifications because they're "too hard" isn't how you get interoperability |
| 02:47 | <mcarter> | our tcpconnection spec can say that you can't use a HEAD request. If you do, the server can respond however it wants because its not a tcpconnection handshake |
| 02:47 | <othermaciej> | I think replying with a 501 would be valid |
| 02:47 | <othermaciej> | (are there any methods that HTTP requires be supported on any resource?) |
| 02:48 | <Hixie> | so now i have to actually check the method |
| 02:48 | <Hixie> | which is imho ridiculous given that what i want to do is just open a socket |
| 02:48 | <mcarter> | Hixie, let me put together an example of this before you pass judgement on how hard it would be |
| 02:49 | <Hixie> | people are going to just skip the steps that aren't required, and you'll end up with servers that open tcp connections for HEAD requests with no UPGRADE or whatever |
| 02:49 | <othermaciej> | I don't think "model train controller" is the common use case |
| 02:50 | <othermaciej> | many interesting use cases require authentication |
| 02:50 | <Hixie> | the train controller required authentication too, actually |
| 02:50 | <othermaciej> | chat, calendar event notification stream, notification stream of twitter messages posted by my contacts |
| 02:50 | <Hixie> | just send the cookie down the pipe |
| 02:50 | <Hixie> | what's the problem with that? |
| 02:51 | <othermaciej> | prevents use of httpOnly cookies to mitigate cookie stealing attacks |
| 02:51 | <othermaciej> | (assuming you are sending the cookie for a different site) |
| 02:51 | <mcarter> | Hixie, also you couldn't have an auth reverse proxy that checks the cookie on the way in to perform authentication |
| 02:51 | <othermaciej> | and then the server and the site vending the cookie have to communicate out of band |
| 02:51 | <othermaciej> | to figure out if the cookie is valid |
| 02:52 | <Hixie> | actually sending third-party cookies to identify the user to a host that's not from the same origin would be an interesting problem |
| 02:52 | <Hixie> | same problem we have with XXX |
| 02:52 | <Hixie> | maybe whatever solution we come up with for XXX can apply here |
| 02:53 | <Hixie> | we could certainly define the api in such a way that cookies and http auth credentials are also sent down the pipe in the handshake |
| 02:53 | <Hixie> | without leveraging the six ton http server |
| 02:54 | <Facedown> | Is there any point to using the type attribute of the script element? |
| 02:54 | <Hixie> | Facedown: not really |
| 02:54 | <Facedown> | I know language is deprecated and type="text/javascript" doesnt really have any effect |
| 02:54 | <mcarter> | Hixie, is there a reason not to arrange that data in a way that looks as close to http as possible, so as to avoid confusing intermediaries? |
| 02:54 | <Facedown> | I guess people just put it there so there's at least one attribute, heh |
| 02:55 | <Hixie> | mcarter: i don't mind it looking like HTTP so long as it isn't HTTP |
| 02:55 | <Facedown> | Oh yeah, the validator and spec do say its required in strict though |
| 02:55 | <Hixie> | Facedown: in html5 it's optional |
| 02:55 | <Facedown> | but isnt there a more correct value? like text/ecmascript? |
| 02:55 | <Hixie> | Facedown: text/javascript is the right value |
| 02:55 | <Facedown> | since javascript isnt the real name |
| 02:55 | <Facedown> | hm |
| 02:55 | <Facedown> | err, application/javascript |
| 02:55 | <Facedown> | http://www.ietf.org/rfc/rfc4329.txt |
| 02:56 | <Facedown> | someone told me about this.. not even sure about it |
| 02:57 | <mcarter> | So what information have we identified so far that we need in the handshake? |
| 02:57 | <mcarter> | 1) Host header, 2) URI, 3) Cookies, 4) referrer |
| 02:59 | <jacobolus> | Facedown: you can just leave it off |
| 03:00 | <jacobolus> | Facedown: all the browsers will know it's javascript |
| 03:00 | <jacobolus> | in html5, it is optional |
| 03:00 | <jacobolus> | so if you use an html5 conformance checker, it will be fine |
| 03:01 | <jacobolus> | Facedown: there's no compelling reason to include it, and it just adds extra characters to your file |
| 03:06 | <jacobolus> | Hixie: why are you so afraid of browsers sending bizarre parts of HTTP as part of this handshake? |
| 03:06 | <jacobolus> | Hixie: aren't there plenty of obscure HTTP features ignored by existing web servers? |
| 03:07 | <Hixie> | jacobolus: i'm worried about someone browsing to that URL and getting back something that is an infinite connection, yes |
| 03:07 | <Philip`> | jacobolus: There are plenty of web servers that break on non-obscure features like HEAD, and it might be nice to not encourage that |
| 03:07 | <Hixie> | anyway, bbiab |
| 03:08 | <jacobolus> | Hixie: I see. it seems like that could be avoided |
| 03:09 | <mcarter> | Hixie, we could use something like OPTIONS as our handshake method... something that a user will never cause to be sent just by browsing |
| 03:10 | <Philip`> | mcarter: What would the server do when the user just sends a GET? |
| 03:11 | <mcarter> | Philip`, send back either a 404, 400, or some status code as indicated in our tcp handshake spec |
| 03:12 | <mcarter> | (while '\r\n\r\n' not in self.buffer) { self.buffer += sock.recv() }; try { assert buffer.startswith('OPTIONS') } catch { sock.send('HTTP/1.x 400 Invalid Handshake\r\n\r\n') } |
| 03:12 | <mcarter> | or something like that |
| 03:13 | <Philip`> | (That try/assert/catch thing looks like an awkward way of writing 'if' :-) ) |
| 03:21 | <mcarter> | Philip`, heh, my only point is that you can just assume the request looks a certain way and just catch any errors if the assumption is wrong |
| 05:35 | <Hixie> | mcarter: why would people not just do (while '\r\n\r\n' not in self.buffer) { self.buffer += sock.recv() }; without the other checks? |
| 05:38 | <mcarter> | Hixie, I see, you're worried about server implementors sending back the wrong thing thus making it possible for a browser to directly connect to a tcp handshake server and get an infinite response |
| 05:39 | <mcarter> | Hixie, in which case, the proper response for a tcp handshake should be to send back a content-length: 0 as part of the headers |
| 05:39 | <Hixie> | i'm worried about any protocol that relies on the author having to do something which they don't get any direct benefit from |
| 05:39 | <Hixie> | because the web shows that authors will not bother |
| 05:40 | <jacobolus> | Hixie: how can you possibly prevent that? |
| 05:40 | <mcarter> | its not clear to me that its a real problem for them to actually ignore the handshake's exact protocol |
| 05:40 | <Hixie> | jacobolus: by not requiring them to do anything other than what they need |
| 05:40 | <mcarter> | if they ignore the protocol, and if someone manages to point an http browser at the tcp server, then shouldn't they get an erroneous response? |
| 05:40 | <Hixie> | mcarter: i'm not writing a spec that says "you must do x" if not doing x will work just as well |
| 05:41 | <jacobolus> | Hixie: you're basically afraid of web servers implementing things such that web browsers could hang. but it seems like that becomes a browser bug, no? |
| 05:41 | <jacobolus> | (hang or use up resources or whatever) |
| 05:41 | <Hixie> | my concern isn't a specific concern, it's a generic one of not wanting to require things that the author gets no benefit from |
| 05:42 | <mcarter> | Hixie, so i say we require a single thing from server implementors |
| 05:43 | <mcarter> | Hixie, and that is, that they send back a specific http response as their half of the handshake |
| 05:43 | <jacobolus> | the author's benefit is that he'll know the browser is actually speaking the proper protocol. is that not enough benefit to properly implementing the handshake? |
| 05:43 | <mcarter> | Hixie, and if they don't send back that response, then the browser rejects the handshake |
| 05:43 | <Hixie> | jacobolus: obviously not, just look at what authors do with html |
| 05:44 | <Hixie> | mcarter: yup, we can do that. but that means what you described above won't happen |
| 05:45 | <mcarter> | Hixie, that was an example to othermaciej how we can prevent random web pages from appearing to hang when users mistakenly navigate to them. the better solution is to require a Content-Length: 0 header, or even a couple dozen bytes in the body which are an error message "You shouldn't be seeing htis page... Go somewhere else." |
| 05:45 | <mcarter> | Hixie, but i see where you're coming from |
| 05:46 | <othermaciej> | mcarter: already now if you navigate your browser to a persistent XHR stream it may appear to hang |
| 05:46 | <othermaciej> | so I do not see solving this problem as essential |
| 05:47 | <othermaciej> | if you browse to reasources not meant to be browsed to directly, weird shit may happen, tough cookies |
| 05:47 | <mcarter> | othermaciej, oh, that wasn't an example for you. it was for Hixie. sorry for the mixup |
| 05:48 | <othermaciej> | perhaps Hixie will agree with my comments as well, since they reduce the burden of what is required on server implementors |
| 05:50 | <Hixie> | i could see an argument for making the handshake look much more like http |
| 05:51 | <Hixie> | but that would not work with proxies |
| 05:51 | <Hixie> | and would not be http-over-port-80 |
| 05:51 | <othermaciej> | you'd have to use CONNECT to tunnel through proxies on the client side |
| 05:51 | <Hixie> | and would in fact not seem to solve any of the purported problems with the current proposal |
| 05:51 | <mcarter> | oh but it would. just make sure you send the CONNECT for the proxy |
| 05:51 | <Hixie> | sure, but we can do CONNECT regardless of what else we do |
| 05:52 | <othermaciej> | and it would solve the URI addressing, lack of cookies, and unable-to-use-web-security-model issues |
| 05:52 | <mcarter> | I'm not clear what the purported problems are with the current proposal. I saw at least one problem, like the dns rebinding attack, and this solves it |
| 05:52 | <mcarter> | Hixie, so CONNECT should happen in any case, and its not really an issue in the non/http discussion |
| 05:53 | <Hixie> | right |
| 05:53 | <Hixie> | it wouldn't solve the uri addressing really |
| 05:53 | <Hixie> | unless we invent a new uri scheme |
| 05:53 | <mcarter> | I'm not sure I follow |
| 05:53 | <Hixie> | ok let me rephrase taht |
| 05:53 | <Hixie> | it isn't necessary to solve the uri addressing issue, or the cookie issue, etc |
| 05:54 | othermaciej | waits for Hixie to expand on that |
| 05:55 | <Hixie> | we can add Host:, Cookie:, etc, to any protocol |
| 05:55 | <Hixie> | doesn't have to look like http |
| 05:55 | <mcarter> | while they aren't absolutely critical issues to have full duplex communication, i think you can spend a little and get a lot by having the client provide the extra information, and format it like http. |
| 05:55 | <Hixie> | i'm all for having that information |
| 05:55 | <Hixie> | i'm just saying that has nothing to do with it being http or not |
| 05:55 | <Hixie> | or http-like, rather |
| 05:55 | <mcarter> | ok |
| 05:56 | <othermaciej> | cookie depends on a host-port-scheme origin though |
| 05:56 | <mcarter> | I think it would be good to look like http because then http parsing libraries would, out of the box, be able to parse it and extract that information. Furthermore, load balancers and authentication reverse proxies could be used AS IS |
| 05:56 | <othermaciej> | so to share cookies with a web server you have to be on the same scheme and port |
| 05:56 | <mcarter> | Hixie, furthermore, you avoid the HTTPS virtual hosting issue that was solved with TLS |
| 05:57 | <mcarter> | Hixie, I'm not sure what the downside of making it look like http is |
| 05:57 | <othermaciej> | I agree you can add Host:, URI-based addressing, and a version of Cookie: that is separate from http cookies to any protocol |
| 05:57 | <othermaciej> | at some level of http-like feature additions it starts to look a lot like http though |
| 05:57 | <Hixie> | othermaciej: yes, the cookies wouldn't get shared if you connected to another server (another port) |
| 05:58 | <Hixie> | othermaciej: but how am i gonna get apache to give me the socket anyway? |
| 05:58 | <Hixie> | mcarter: the only downside is that it's a lie and the httpwg will come and stone us |
| 05:59 | <mcarter> | Hixie, I am suggesting that we make it VERY clear that we aren't HTTP, rather a subset used for TCP handshakes |
| 05:59 | <othermaciej> | Hixie: with a custom method or similar mechanism one could presumably make an apache module (which is why I think making one would be an interesting proof-of-concept excercise) |
| 05:59 | <mcarter> | Hixie, they can't be seriously upset if another protocol borrows some formatting from http |
| 05:59 | <Hixie> | mcarter: hahaha |
| 05:59 | <Hixie> | mcarter: i see you haven't spent much time working with standards committees |
| 06:00 | <Hixie> | othermaciej: making an apache module is more than 10 lines of perl |
| 06:00 | <Hixie> | othermaciej: though i agree that in this case it would be ok |
| 06:00 | <othermaciej> | Hixie: sure, but if you don't want to share the port the apache server has bound, you would not need the module |
| 06:00 | <Hixie> | othermaciej: as it would allow it for the big players or people using server extensions |
| 06:00 | <Hixie> | othermaciej: right |
| 06:00 | <othermaciej> | if the http subset for the handhsake is simple enough |
| 06:00 | <Hixie> | othermaciej: yeah that makes sense |
| 06:00 | <Hixie> | i'm ok with that |
| 06:02 | <mcarter> | Hixie, couldn't we call this TCP over HTTP? The server isn't required to go support all of http, though its welcome to |
| 06:02 | <Hixie> | mcarter: optional features are bad for interop |
| 06:02 | <mcarter> | Hixie, as far as I can tell, this is almost the EXACT use case for which they added the upgrade header |
| 06:02 | <othermaciej> | mcarter: I think it would be well advised to define what a server should do when it only supports the handshake subset of TCP |
| 06:03 | <othermaciej> | er |
| 06:03 | <othermaciej> | handshake subset of HTTP |
| 06:03 | <Hixie> | mcarter: i agree that this is why upgrade exists |
| 06:03 | <Hixie> | mcarter: but since we can't guarentee that people will test for it |
| 06:03 | <Hixie> | mcarter: it doesn't really help us |
| 06:03 | <othermaciej> | such as return a 501 error for any other request |
| 06:03 | <Hixie> | we can't define what a "server should do" |
| 06:04 | <Hixie> | when the server is written by random authors |
| 06:04 | <Hixie> | it's akin to defining how you should use a dom api |
| 06:04 | <mcarter> | Hixie, if someone writes a non-compliant http server that likes to always assume a connection is going to be upgraded, then how is that our problem, OR httpwg's problem? |
| 06:04 | <mcarter> | Hixie, the same argument can be made against doing TLS with the upgrade header. Server implementors might just go an upgrade on their own without testing for it. |
| 06:04 | <Hixie> | mcarter: sure |
| 06:04 | <Hixie> | mcarter: i |
| 06:04 | <Hixie> | er |
| 06:05 | <othermaciej> | I think Hixie assumes writing this kind of server from scratch will be more common than writing full-fledged http servers |
| 06:05 | <Hixie> | mcarter: i'm just saying it doesn't matter that upgrade exists :-) |
| 06:05 | <othermaciej> | although there are quite a few http server implementations out there |
| 06:05 | <othermaciej> | and usually their level of non-compliance is within tolerable limits for UAs |
| 06:06 | <othermaciej> | (I wonder if there is a protocol-level HTTP Validator tool available) |
| 06:06 | <Hixie> | let's just say http isn't how it would have been if i'd been writing the spec either :-) |
| 06:08 | <mcarter> | Hixie, I'm still missing some of the logic. That is, the TLS spec went and used the upgrade header, even though server implementors of TLS might not have actually enforced that header and instead treated all requests like they were part of a TLS handshake. Now we're saying, lets follow suit and do exactly that with our tcp protocol. Which part of this will make the httpwg mad? |
| 06:09 | <Hixie> | the part where you can connect to something that isn't an http server, send it something that looks exactly like an http response, and be compliant, despite the fact that the server doesn't know the first thing about http |
| 06:09 | <Hixie> | i should clarify |
| 06:09 | <Hixie> | that annoying the httpwg isn't necessarily a blocking problem |
| 06:09 | <Hixie> | especially if there are compelling reasons to go this route, as there appear to be |
| 06:11 | <jacobolus> | Hixie: I think you should go rewrite the HTTP spec, and get rid of all the confusing shit in it ;) |
| 06:11 | <Hixie> | http5 is gsnedders' baby |
| 06:11 | <othermaciej> | I am amazed at how technically obscure the http spec is, while at the same time being incredibly unclear on the most basic things |
| 06:12 | <jacobolus> | mcarter has learned to love the http spec these last several months, right? |
| 06:12 | <jacobolus> | he's been having fun writing things like proxies :) |
| 06:12 | <mcarter> | Hixie, ok. in terms of explaining it in way that won't make anyone mad is this: HTTP Servers can also be HTTP/TCP servers if they support Upgrade: tcp. Similarly, anyone who wants to can go write an http or http/tcp server even if it isn't fully compliant (which http server is FULLY compliant anyway?) |
| 06:13 | <Hixie> | othermaciej: like svg? :-D |
| 06:13 | <mcarter> | at any rate, like I said before, I'll draw some documents up that outline some of this stuff |
| 06:13 | <Hixie> | that'd be great |
| 06:13 | <Hixie> | i think we've made major progress here |
| 06:13 | <mcarter> | I sent an api change proposal in for TCPConnnection today, whenever you see it |
| 06:13 | <mcarter> | it just suggests adding a connect() method, and an extra readyState |
| 06:13 | <jacobolus> | yep. and then just make sure that HTTP/TCP is as minimal as possible. :) |
| 06:14 | <othermaciej> | mcarter: I don't like explicit connect |
| 06:14 | <jacobolus> | so that the 10-lines-of-perl constituency stays happy :) |
| 06:15 | <mcarter> | othermaciej, the api change is mostly for the reason of re-using the TCPConnection objects much like we re-use XHR connections |
| 06:15 | <othermaciej> | mcarter: because, first of all, reusing a connection is more confusing than helpful |
| 06:15 | <jacobolus> | Hixie: do you have docs about your train set thing? |
| 06:15 | <othermaciej> | mcarter: and second, because it adds an additional opportunity to use the API wrong, since you can accidentally make calls before connecting |
| 06:15 | <othermaciej> | the current API does not have the possibility of making that mistake |
| 06:16 | <mcarter> | othermaciej, Also, I don't fully feel comfortable with the idea that I must possess deep understanding of javascript concurrency to know when I need to attach the callbacks |
| 06:16 | <othermaciej> | mcarter: ain't no such thing as javascript concurrency |
| 06:16 | <mcarter> | othermaciej, if i create a TCPConnection object, at what point does it *Actually* initiate the connection? when my function that created it returns? when the function that called it returns? |
| 06:16 | <Hixie> | jacobolus: i don't believe so |
| 06:17 | <mcarter> | othermaciej, indeed, but it doesn't seem wise to tie your apis to the idea that there is no concurrency in javascript |
| 06:17 | <mcarter> | othermaciej, at least not where its easy to avoid doing so |
| 06:17 | <othermaciej> | mcarter: as with XHR, you will not in fact get callbacks for network activity until the current script execution (whether <script>, event or timer initiated) finishes |
| 06:17 | <othermaciej> | (well, as with async XHR) |
| 06:17 | <othermaciej> | I don't think it is possible to safely change this rule about callbacks for network activity in any case |
| 06:17 | <mcarter> | othermaciej, so, I suppose we aren't allowing for synchronous tcp connection, ever? |
| 06:17 | <othermaciej> | but yes, programming in the browser there is an implicit "event loop" |
| 06:18 | <othermaciej> | mcarter: no way |
| 06:18 | <Hixie> | good lord no |
| 06:18 | <othermaciej> | or at least, over my dead body |
| 06:18 | <Hixie> | no synchronous anything over the network |
| 06:18 | <jacobolus> | yes, that sounds like a bad idea |
| 06:18 | <Hixie> | i don't know if i'd defend against that with my life, per se |
| 06:18 | <Hixie> | but still |
| 06:18 | <mcarter> | I certainly wouldn't want such a thing, but aren't there being arrangements made for threading in some future javascript? |
| 06:19 | <othermaciej> | mcarter: even with threads, I am not sure synchronous networking is particularly valuable |
| 06:19 | <mcarter> | othermaciej, I certainly don't want to argue that point |
| 06:19 | <othermaciej> | for exaple, Gears has its workers and they are adding async networking only, I believe (their HTTPRequest thing) |
| 06:21 | <jacobolus> | mcarter: is there any other particular reason to not connect immediately? |
| 06:21 | <jacobolus> | mcarter: why does someone need to add a bunch of callbacks at indeterminate times, then sometime way later actually connect? |
| 06:21 | <mcarter> | besides re-use of the connection object, as a programmer it just seems strange to me to have something where the constructor hits the network. particularly in the context of this javascript event loop -- I can see someone making a mistake about when they should attach the callback |
| 06:22 | <othermaciej> | mcarter: you can't reuse a socket |
| 06:22 | <othermaciej> | or a file descriptor |
| 06:22 | <othermaciej> | or a C stdio FILE* |
| 06:22 | <othermaciej> | or a perl file handle |
| 06:22 | <mcarter> | i get your point |
| 06:22 | <mcarter> | if anything thats an argument against re-using the XHR request object, imo |
| 06:23 | <Hixie> | xhr is badly designed |
| 06:23 | <othermaciej> | yes, but we have to support that for legacy compatibility |
| 06:23 | <othermaciej> | XHR is not what I would have designed |
| 06:23 | <Hixie> | basically anything i didn't invent is badly designed, it's really very simple |
| 06:23 | Hixie | ducks |
| 06:23 | <mcarter> | haha! |
| 06:23 | <othermaciej> | plus anything you did invent |
| 06:24 | <othermaciej> | but some things are more badly designed than others |
| 06:25 | <mcarter> | Hixie, how did this happen, exactly? |
| 06:25 | <jacobolus> | Hixie: you need to speed up your pace of invention then |
| 06:26 | <Hixie> | mcarter: which? |
| 06:26 | <mcarter> | Hixie, i mean, you seem to be in a position of some power over the browsers. I mean, i see the IE8 team emailing you about postMessage and such |
| 06:26 | <mcarter> | it seems so unprecedented |
| 06:26 | <mcarter> | (I think its great... a vast improvement) |
| 06:28 | <Hixie> | mcarter: i've only got as much power as they give me |
| 06:28 | <Hixie> | mcarter: my secret is giving them mostly what they want |
| 06:28 | <Hixie> | oh and doing a lot of work |
| 06:28 | <mcarter> | Is this your day job? |
| 06:28 | <Hixie> | people tend to defer to whoever is actually doing the work |
| 06:29 | <Hixie> | it's easier than doing it themselves |
| 06:29 | <Hixie> | mcarter: yes, google pays me to edit html5 full time |
| 06:29 | <othermaciej> | html5 has turned out to be an area where doing things through standards is less painful than just inventing proprietary features |
| 06:30 | <othermaciej> | this is not always the case with web standards |
| 06:30 | <Hixie> | yeah |
| 06:30 | <Hixie> | css being the prime example these days |
| 06:30 | <othermaciej> | I predict everything hyatt announced css-wise for the past 6 months will still be in committee 5 years from now |
| 06:31 | <Hixie> | unless someone writes a spec yes |
| 06:31 | <othermaciej> | I gotta head home |
| 06:31 | <othermaciej> | later folks |
| 06:31 | <mcarter> | whats the timeframe with html5? will it continue to be continuously updated? |
| 06:31 | <Hixie> | later |
| 06:31 | <Hixie> | mcarter: http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE |
| 06:32 | <mcarter> | oh wow |
| 06:32 | <mcarter> | thats a long time line |
| 06:33 | <jacobolus> | Hixie: so will there be something beyond html5 by halfway through that process? |
| 06:33 | <Hixie> | maybe |
| 06:33 | <Hixie> | i don't expect to do html6 |
| 06:33 | <Hixie> | i mostly started working on html5 because at the time, html was the spec in most dire need of work |
| 06:33 | <jacobolus> | right |
| 06:34 | <jacobolus> | so do you think all of the recent webkit css changes will actually be picked up by other browsers? |
| 06:34 | <jacobolus> | or will they remain limited to dashboard widgets, etc. |
| 06:34 | <roc> | some of them I want to implement in Gecko |
| 06:34 | <roc> | others I don't |
| 06:34 | <jacobolus> | Hixie: what is in next-most-dire need? |
| 06:35 | <Hixie> | jacobolus: probably DOM Core, CSS, and HTTP. And SVG. |
| 06:35 | <roc> | fortunately the ones I want are the ones Apple is producing draft specs for |
| 06:35 | <jacobolus> | svg isn't a lost cause? :p |
| 06:35 | <Hixie> | css would be tough to fix because it has a large political quagmire around it |
| 06:35 | <Hixie> | svg too |
| 06:36 | <Hixie> | http could probably be fixed by ignoring the httpwg without too much fallout |
| 06:36 | <jacobolus> | how would anyone possibly fix http? |
| 06:36 | <jacobolus> | what could be done? |
| 06:36 | <Hixie> | dom core would be the easiest to fix |
| 06:36 | <jacobolus> | yes |
| 06:36 | <Hixie> | well, by "fix" i mean "write a real spec" |
| 06:36 | <Hixie> | that defines error handling, actual behaviour, etc |
| 06:36 | <jacobolus> | what's broken about DOM core now? |
| 06:36 | <Hixie> | and strips all the crap |
| 06:36 | <Hixie> | jacobolus: the DOM Core spec is far too vague |
| 06:36 | <Hixie> | in fact, all the DOM specs are too vague |
| 06:37 | <jacobolus> | are the implementations vastly inconsistent then? |
| 06:37 | <jacobolus> | while still meeting the spec? |
| 06:40 | <roc> | a lot of HTTP implementations are just plain broken |
| 06:40 | <roc> | especially proxies |
| 06:40 | <roc> | not much anyone can do about that |
| 06:41 | <Hixie> | jacobolus: not especially more than html4 implementations were, but a vague spec means it's hard to write a new browser |
| 06:41 | <Hixie> | and we need it to be possible to write new UAs so that we can have competition |
| 06:41 | <jacobolus> | roc: yes, I was talking about DOM. I know http is nasty :) |
| 07:18 | gsnedders | cradles his baby |
| 07:18 | <gsnedders> | (seeming Hixie called it my baby) |
| 08:01 | <roc> | Ian, please lean on the GMail team to implement HTML5 link handler stuff |
| 08:01 | <roc> | for mailto: |
| 08:02 | <roc> | I really need it! |
| 08:02 | gsnedders | wants mid: support in Mail.app |
| 08:03 | <Hixie> | roc: i expect they'll do it shortly after ff3 sips |
| 08:03 | <Hixie> | ships |
| 08:03 | <roc> | Yahoo's already done it :-( |
| 08:04 | <roc> | FF3 has UI to select the handler and Yahoo's on it and Gmail isn't |
| 08:09 | <Hixie> | we don't, as a rule, pay much attention to what the competition does, or at least, we don't let it dictate policy :-) |
| 08:10 | <gsnedders> | Peh! You should! :P |
| 08:10 | <gsnedders> | Actually, I don't eat my own dogfood. I don't really pay attention to the httpbis wg |
| 08:42 | <annevk> | I found http://www.htmlfive.net/ which just seems to be a rip of the WHATWG blog with the intention to make money out of it |
| 08:43 | <annevk> | I found it through: http://www.whathuhstudios.com/press/2008/04/24/html5/ |
| 08:43 | <Hixie> | terrible |
| 08:43 | <annevk> | I have the feeling you're being sarcastig :) |
| 08:44 | <Lachy> | well, they've violated the copyright license |
| 08:44 | <Lachy> | there's no mention of the MIT license anywhere and no attribution |
| 08:45 | <annevk> | attribution is not required |
| 08:46 | <Lachy> | actually, yes it is. At least in Australia it is because attribution is considered a basic moral right |
| 08:46 | <Hixie> | our goal with the whatwg blog is to get more people to know about stuff right? |
| 08:47 | <Lachy> | unless otherwise stated by the creator, attribution is always required otherwise it's plagiarism |
| 08:47 | <annevk> | Yeah, guess I was just upset it wasn't a genuine fansite :) |
| 08:47 | <Hixie> | oh there's no doubt that this is immoral |
| 08:47 | <Hixie> | but i recommend not worrying about it |
| 08:48 | <Lachy> | I don't have a problem with them syndicating the posts. That's why we put a free license on it. |
| 08:48 | <Hixie> | yeah but just copying them with no attribution or anything is just nasty |
| 08:49 | <Lachy> | I will see if I can find contact information and ask them to give attribution |
| 08:53 | <Hixie> | ask them to buy us video games with some of the money they make, too |
| 08:55 | <Lachy> | I can't seem to find contact info. Though, there is only one site listed in the blog roll, I'm not certain that he's the owner of the site. |
| 08:55 | <Lachy> | WHOIS info for the domain only shows dreamhost contact info. |
| 08:59 | <Lachy> | wow, that's a useless contact form! http://blog.nprignano.com/contact/message Not even a text box :-( |
| 08:59 | <hsivonen> | it seems to me that the foremost practical concern is getting Google and Technorati consider it a splog |
| 08:59 | <hsivonen> | perhaps they both already do, because it isn't showing up on my vanity feeds |
| 09:00 | <Lachy> | hsivonen, the domain was only just registered 2 days ago |
| 09:00 | <Lachy> | so it will take a few weeks before it shows up in google |
| 09:00 | <hsivonen> | annevk: what's the chance of getting an XML5 tokenizer spec as a delta spec over the HTML5 tokenization spec? |
| 09:01 | <othermaciej> | delta specs suck |
| 09:01 | <hsivonen> | othermaciej: they do, but it seems to me that XML5 and HTML5 will share so much tokenization code that I don't want to write another tokenizer from scratch |
| 09:02 | <othermaciej> | hsivonen: well I don't know what to expect from XML5 so I can't predict if that will be sensible |
| 09:03 | <othermaciej> | would it, for example, accept unquoted attribute values? |
| 09:05 | <hsivonen> | othermaciej: it seems to me that ideally, the only new states would be for the internal subset and PIs |
| 09:05 | <hsivonen> | and otherwise the delta would be where errors fire |
| 09:06 | <hsivonen> | of course, ideally ideally, the internal subset would be swallowed by a black hole |
| 09:06 | <othermaciej> | well <foo/> would have to do something different, as well |
| 09:06 | <othermaciej> | and it has to recognize <![CDATA[ |
| 09:07 | <hsivonen> | othermaciej: but we already have those in the HTML5 tokenizer now |
| 09:07 | jwalden | finishes rewriting postMessage for the third time |
| 09:07 | <jwalden> | "rewriting", that is |
| 09:08 | <jwalden> | bloody spec changes :-) |
| 09:08 | <othermaciej> | interesting |
| 09:09 | <othermaciej> | I still hate delta specs though |
| 09:09 | <othermaciej> | yeah we have to fix WebKit's postMessage now |
| 09:09 | <hsivonen> | othermaciej: well if you can get Hixie to integrate XML5 tokenization into the HTML5 tokenizer spec... |
| 09:10 | <jwalden> | actually, fixing the implementation's comparatively easy, it's all those stupid tests I've written that are taking the lion's share of the time to change |
| 09:10 | <jwalden> | and all the tests others have written that use postMessage since it was introduced |
| 09:10 | <jwalden> | ;-) |
| 09:10 | jwalden | makes note never to write tests ever again |
| 09:11 | <jwalden> | all they cause is more work |
| 09:11 | <Hixie> | :-/ |
| 09:11 | <jwalden> | I kid, I kid! |
| 09:11 | jwalden | channels the Dread Pirate Roberts |
| 09:12 | <othermaciej> | never go in against a Swissilian when specs are on the line |
| 09:12 | <jwalden> | haha, haha, ha- |
| 09:15 | <hsivonen> | Hixie: so far, the YSTEM and UBLIC cases have translated into states very nicely |
| 09:15 | <hsivonen> | Hixie: I expect breaking up the entity stuff into states to be a tad ugliers |
| 09:15 | <hsivonen> | uglier |
| 09:22 | <hsivonen> | I wonder if there are Java to C++ source level translators |
| 09:29 | <hsivonen> | does anyone know how IBM maintains their dual Java/C++ libraries? |
| 09:30 | <othermaciej> | 3 levels of committee review for every checkin? |
| 09:31 | <hsivonen> | othermaciej: could be :-/ |
| 09:39 | <mpt> | krijn, is your IRC logging software publicly available? |
| 09:39 | <krijn> | mpt: nope, sorry |
| 09:40 | <krijn> | mpt: I'm too ashamed about the source code :) |
| 09:40 | <krijn> | And it's not really logging software, the logging is done by mIRC |
| 09:40 | <krijn> | I only parse the logfiles with some PHP |
| 09:40 | <krijn> | Hence the shame ;) |
| 09:40 | <mpt> | ah |
| 09:58 | <Philip`> | http://blog.facebook.com/atom.php - feeds are always more fun when you stick random binary garbage in them |
| 10:20 | <sverrej> | rn |
| 13:40 | <hsivonen> | http://lists.w3.org/Archives/Public/www-validator/2008Apr/0136.html |
| 13:46 | <hsivonen> | aside: Typinator is awasome for refactoring code |
| 13:46 | <hsivonen> | awesome |
| 15:40 | <hsivonen> | aargh. I regressed ¬i; |
| 15:40 | hsivonen | doesn't like ¬i; |
| 15:40 | <Lachy> | Hixie, it would help if the spec had links from each section in the single-page version of the spec to same section in the multipage version. |
| 15:41 | <Lachy> | that way, when I want to give a link to someone, I don't need to send them to the full size spec, or take the time to manually find the section in the multipage version |
| 15:48 | <Lachy> | hsivonen, there is no ¬i; listed in the spec. Did you mean ∉? |
| 15:49 | <hsivonen> | Lachy: no, I meant ¬i; |
| 15:49 | <Lachy> | Hixie, ¬ is listed twice in the table of entities |
| 15:49 | <hsivonen> | Lachy: I've fixed it now |
| 15:49 | <hsivonen> | Lachy: ¬i; is a tricky error cases |
| 15:49 | <hsivonen> | s/cases/case/ |
| 15:50 | <Lachy> | ok |
| 15:51 | <Philip`> | Do the new entities introduce any more cases where one entity is a prefix of another? |
| 15:51 | <hsivonen> | Philip`: I don't know. I'm keeping my head in sand and hoping they go away. |
| 16:03 | <Lachy> | Philip`, do you mean like ¬ ∉ ∉ ⋷ ⋶ ∌ etc...? |
| 16:04 | <Lachy> | looks like there are several, and I only looked in one small section of the table |
| 16:05 | <takkaria> | Lachy: ¬ and ¬ are not the same entity |
| 16:05 | <takkaria> | well, they are, but the duplication is intentional |
| 16:05 | <Lachy> | really? |
| 16:05 | <takkaria> | Lachy: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tokenisation.html , the "anything else" section at the end |
| 16:05 | <takkaria> | yeah |
| 16:05 | <Lachy> | oh, crap. maybe it would help if I actually read the spec one day |
| 16:08 | <Lachy> | takkaria, which "anything else" section are you referring to? |
| 16:12 | <takkaria> | Lachy: very end of that page |
| 16:15 | <Lachy> | ok. I think the duplication is annoying. Surely there's a way to write the spec such that you don't need to have the same entity listed twice with and without the semi-colon |
| 16:15 | <takkaria> | there would be if every entity was allowed to leave out the semicolon |
| 16:16 | <takkaria> | but afaik, that's not the case |
| 16:17 | <Lachy> | couldn't we add a 3rd column to the table that indicated whether or not a semi-colon was required |
| 16:17 | <Lachy> | for the purpose of parsing |
| 16:17 | <Lachy> | not for conformance |
| 16:18 | <takkaria> | I'm not in favour of that because it makes it harder to build a list of entities for implementations |
| 16:19 | <takkaria> | automatically, that is |
| 16:19 | Philip` | agrees with takkaria |
| 16:19 | <Philip`> | It's nice and easy to just use a regexp to convert the table into a list of entity strings, and it'd need an extra line of code if the semicolonity was a separate column |
| 16:20 | <takkaria> | oh, you use a regex? I use xslt. :) |
| 16:20 | <Philip`> | Yuck :-p |
| 16:21 | <takkaria> | only 11 lines of it, mind |
| 16:22 | <Philip`> | I'm guessing mine was only a single line, because I can't see that I saved the code in a file anywhere |
| 16:24 | <Lachy> | ok, fine. I'll put a table targetted at authors in the HTML5 author guide which lists them only once |
| 16:25 | <Philip`> | A table for authors should show what the character looks like, too |
| 16:25 | <Lachy> | yep, it will list everthing about the character |
| 16:25 | Philip` | wonders if the characters could be categorised into usefulness, rather than having the standard unreadable big list |
| 16:26 | <Lachy> | code point, character name, link to further info about the character, numeric (hex and decimal) character refs, etc. |
| 16:27 | <Lachy> | they were grouped into categories in HTML4 |
| 16:27 | <Philip`> | Might be nice to not scare authors by having a really wide table, too :-) |
| 16:28 | <takkaria> | Lachy: how about including the character the entity represents too? |
| 16:28 | <Lachy> | I could make it interactive and let authors show and hide columns they want to see |
| 16:29 | <Lachy> | takkaria, yeah, Philip` already mentioned that |
| 16:29 | <takkaria> | oh, I missed that. :) |
| 16:29 | <Lachy> | see, I'm not the only one who doesn't read around here :-P |
| 16:34 | <takkaria> | I only remember that because it was around the time I got interested in html5 parsing and it was the only bit of the conversation I understood |
| 16:45 | <hsivonen> | Lachy: the entity table is fine as is |
| 16:46 | <hsivonen> | that is, with duplication |
| 16:46 | <hsivonen> | Lachy: making the table neater in spec would only cause more opportunity for implementation error |
| 16:47 | <Lachy> | hsivonen, Philip` and takkaria already told me that. |
| 16:54 | <takkaria> | there seems to be a "no-one is reading what anyone else has said" bug going round today |
| 16:54 | <takkaria> | let's just hope Hixie doesn't get it |
| 16:56 | <Philip`> | Hey, has anyone noticed the entity table lists "not" twice? |
| 19:34 | <mcarter> | You know, if a TCPConnection constructor causes a network access, then prototype-based subclassing becomes impossible |
| 21:38 | Philip` | discovers that http://www.aaronsw.com/2002/diff/ quite badly fails to work |
| 21:39 | <Philip`> | since it totally ignores element nesting, and just sticks <ins> and </ins> at pretty much arbitrary points in the document, which makes browsers cry |
| 21:40 | <Philip`> | but http://htmlwg.mn.aptest.com/viewcvs/viewcvs.cgi/htmldiff/ actually works properly (and it doesn't make XHTML become ill-formed), which is nice, though the code's use of regexps for parsing looks a little dodgy |
| 21:41 | <Dashiva> | Is there a "proper" way to <ins> the transition Apple <em>pie</em> -> Apple banana <em>pan pie</em>? |
| 21:43 | <Philip`> | Is anything wrong with Apple <ins>banana </ins><em><ins>pan </ins>pie</em>? |
| 21:43 | <Philip`> | You lose the information that both insertions were simultaneous, but I'm not sure what you'd want that information for |
| 21:44 | <Dashiva> | There's also Apple <ins>banana <em>pan </em></ins><em>pie</em> |
| 21:46 | <Philip`> | That's bad because you can't recover the new piece of markup (Apple banana <em>etc) from the annotated-with-ins markup |
| 21:47 | <Philip`> | You should be able to strip the <del> tags and delete the <ins> content to recover the first diffed document, and vice versa to recover the second |
| 21:48 | <Philip`> | (or at least I'm asserting that you ought to be able to, because that seems like a useful property) |
| 21:48 | <Lachy> | if you need to know the inserts were simultaneous for some reason, use <ins datetime="..."> |
| 21:49 | <Philip`> | Hixie: Has anyone already told you that http://www.whatwg.org/specs/web-apps/current-work/#attributes says "The cite DOM attribute must reflect the element's >cite content attribute." with a stray ">"? |
| 21:50 | <Philip`> | Lachy: That doesn't really tell you they're simultaneous, since it can only have a precision of one second, and it's quite plausible that a heavily-edited document (e.g. the concatenation of all pages on Wikipedia) can have multiple edits per second |
| 21:50 | <Hixie> | oh crap |
| 21:50 | <Hixie> | did i break that recently |
| 21:50 | <Hixie> | sigh |
| 21:52 | <Lachy> | Hey Hixie, if you didn't read the earlier discussion in here about the entity table, just ignore my email about it. It was due to my failure to read the spec properly |
| 21:52 | <Hixie> | already ignored :-D |
| 21:52 | <Lachy> | :-) |
| 21:54 | <gsnedders> | silly Lachy. Can't even read a specification how it says to be read :P |
| 21:57 | <Philip`> | To be fair, if you didn't know how to read the specification then you wouldn't be able to read the part of the specification that says how to read it, so you can be excused |
| 21:57 | <gsnedders> | Hixie: Can you fix that issue? |
| 21:57 | <gsnedders> | (Within the spec, obviously) |
| 21:58 | <Lachy> | gsnedders, if people actually read the spec and knew what they were talking about all the time, joining in on bikeshed discussions wouldn't be nearly as fun! |
| 21:58 | <Dashiva> | gsnedders: We'll fix it the same way we fix content-type detection, maybe? |
| 21:58 | <gsnedders> | Lachy: My. bikeshed. is. green. and. counts. in. micro-seconds. |
| 22:00 | <Lachy> | LOL |
| 22:00 | jwalden | grumbles about midairs |
| 22:01 | <gsnedders> | (see, I know what the thread that made bikeshedding famous was about :P) |
| 22:02 | <Dashiva> | gsnedders: Mine doesn't count, it integrates |
| 22:08 | <Lachy> | so regarding that datetime discussion, since they've still failed to describe valid use cases for BCE or Y10K+ dates in markup, it seems the only possibly valid argument for it is to allow DOMDateTime objects and datetime attributes able to express the same range of values |
| 22:18 | <Dashiva> | Lachy: I'm wondering how they plan to get accurate dates, much less times, for anything that old |
| 22:20 | <Hixie> | anything before the gregorian calendar starts is a non-starter anyway |
| 22:21 | <Lachy> | Dashiva, all of history is recorded in google calendar. :-) |
| 22:23 | <Lachy> | the universe was created in 1970. Anything before then is an epoch fail. |
| 22:29 | <Philip`> | In Y10K we'll all live in space and time won't have a fixed meaning any more, so we'll have already solved all the time problems |
| 22:41 | <Dashiva> | Imagine all the awesome compatability layers we'll get for supporting earth-based dates and times |
| 22:46 | <Lachy> | Maybe we'll just have clocks that compensate for time dialation and maintain earth-time, no matter where we are or how fast we're going. |
| 22:51 | <Philip`> | If you get put in a spaceship in suspended animation, and it's sent at 0.9c to a star a couple of light years away, what time would you say it was when you arrived? |
| 22:54 | <Hixie> | Philip`: "12:00" |
| 22:54 | <Lachy> | Philip`, the question is flawed because you didn't give a start time |
| 22:54 | <Hixie> | (blinking) |
| 22:55 | <Philip`> | Lachy: It's flawed for far more reasons than that :-p |
| 22:56 | <Philip`> | but there are still lots of factors in it that all affect the perception of time, and people probably want to be able to perceive time kind of like how they do now |
| 22:56 | <Lachy> | it also depends if I was taken out of suspended animation when I arrived |
| 22:57 | <Philip`> | It's not very good if their clocks compensate for time dilation so that the space travellers put some food in the oven for 30 seconds and find that it explodes because their clock had automatically slowed down by a factor of ten |
| 22:59 | <Philip`> | Uh |
| 22:59 | <Philip`> | s/oven/microwave/ |
| 22:59 | <Lachy> | some clocks will be relative to the users time frame, others will be relative to earth's |
| 23:01 | <Lachy> | and it will be just aweful if someone set their video timer to record, but forgot to set it by the earth clock. |
| 23:01 | <Philip`> | If the user is suspendedly animated for a year, should their clock stop for that time? |
| 23:02 | <Philip`> | Lachy: That's not going to be a real problem - the broadcasters can just archive all their material, and provide anything on-demand whenever you want it |
| 23:02 | <Hixie> | dude i have to reset my clock after just a few hours of air travel |
| 23:03 | <Lachy> | The person will remain physically the same age, though time will continue to pass around them |
| 23:03 | <Lachy> | so it depends if their clock is in the suspended animation chamber with them |
| 23:04 | <Philip`> | (The only problem is DRM - if it's like the BBC iPlayer where you're only allowed to watch stuff from the past 7 days, that'll be a pain when "7 days" becomes highly relative) |
| 23:04 | <Hixie> | the only really "new" think will be that timezones will differ in relative rate of time as well as offsets |
| 23:04 | <Hixie> | no biggie |
| 23:07 | <Philip`> | I already have enough problems trying to synchronise cron jobs on two machines in different continents, even before worrying about DST, so I'd prefer a better solution for the future |
| 23:08 | <Hixie> | just use UTC |
| 23:08 | <Hixie> | timezones are purely a ui thing |
| 23:08 | <Hixie> | or should be purely a ui thing |
| 23:08 | <Philip`> | Can I make cron use UTC? |
| 23:09 | <Lachy> | Many satellites already compensate for relativistic effects. |
| 23:09 | <Lachy> | Philip`, why can't you juse sent the computer clocks to UTC? |
| 23:09 | <Lachy> | *just |
| 23:09 | <roc> | GPS compensates for relativistic effects |
| 23:10 | <Philip`> | (preferably only for some of the jobs - I want certain things to always happen after I've gone to bed, which is in sync with the local timezone) |
| 23:11 | <Hixie> | when i go to bed really isn't in sync with anything |
| 23:11 | <Hixie> | about the only hour i can guarentee i'm not up 90% of the time is 6:30am - 7:30am local time |
| 23:11 | <Hixie> | and even that is relatively new |
| 23:12 | <Hixie> | showModalDialog() |
| 23:12 | <gsnedders> | The only hour of day when I have never searched Google is 3–4am local time. |
| 23:12 | <Hixie> | any opinions? |
| 23:12 | <gsnedders> | That's a decent indication of when I'm awake. |
| 23:12 | <Hixie> | i'm awake 3am-4am most nights |
| 23:12 | <Philip`> | Lachy: The hardware clocks are set to UTC, but my cron seems to use the system-wide timezone settings (probably so it can schedule things for 3:10am and it won't interrupt any in the middle of their day) |
| 23:12 | gsnedders | notes his sleeping pills are obviously having less affect on him now, as he took one an hour ago |
| 23:12 | <Lachy> | Hixie, I haven't read the spec for showModalDialog(). |
| 23:12 | <Philip`> | s/any/anyone/ |
| 23:12 | <Lachy> | I'm sure I have lots of opinions on it though |
| 23:13 | <Hixie> | there's a spec for it? |
| 23:13 | <Lachy> | s/spec/documentation/ |
| 23:13 | <Hixie> | that's a kind word |
| 23:14 | <Hixie> | holy crap this is an annoying feature |
| 23:14 | <Hixie> | how has it not been abused for ads yet |
| 23:14 | <Hixie> | it blocks all the other tabs! |
| 23:14 | <Lachy> | fine then. s/documentation/breif summary of what it's supposed to do and how it's supposed to be used/ |
| 23:14 | <Philip`> | gsnedders: Hmm, my lowest is 7am (2 searches) and 6am (3 searches), and highest is 10pm (1610 searches) |
| 23:15 | <gsnedders> | Philip`: Over what time period? |
| 23:15 | <Philip`> | gsnedders: All time |
| 23:16 | <gsnedders> | Actually, I tell a lie. Over all time I've made three searches at 3am. |
| 23:16 | <gsnedders> | That is the lowest, though. |
| 23:16 | <Philip`> | Don't ask me what "all time" means |
| 23:16 | <gsnedders> | 6pm is highest at 2007. |
| 23:16 | <Hixie> | my lowest is 5am and 6am, 41 searches each |
| 23:16 | <gsnedders> | Over the quantifiable "last year", I've made no searches 4–6am, about 993 searches at 6pm (the most) |
| 23:16 | <Philip`> | (although if you did ask me, I'd estimate it's about 1.5 years, given the numbers) |
| 23:16 | <Hixie> | and highest is 4pm, 1895 searches |
| 23:17 | <gsnedders> | Saturday has the most searches, and Friday the least |
| 23:17 | <gsnedders> | Feb the most, Jun the least. |
| 23:17 | <gsnedders> | (which is odd seeming it wasn't June when I was away over the summer) |
| 23:18 | <Philip`> | It would be nice if Google Web History wasn't quite so buggy in Opera |
| 23:18 | <Lachy> | where are you all getting stats on how many searches you do? |
| 23:18 | <gsnedders> | Hixie: "live dom viewer" is the fourth most common search for me :) |
| 23:18 | <gsnedders> | Lachy: http://www.google.com/history/ |
| 23:19 | <Philip`> | Lachy: There's an SQL injection vulnerability in google.com so you can just query their whole database directly |
| 23:19 | <Hixie> | Lachy: http://www.google.com/history/trends?hl=en |
| 23:19 | gsnedders | prefers Philip`'s explanation, though |
| 23:20 | <Lachy> | I get no results because I'd never enabled that before now |
| 23:21 | gsnedders | doesn't use bookmarks. |
| 23:21 | gsnedders | uses Google. |
| 23:21 | <Philip`> | My bookmark folders are write-only |
| 23:22 | <gsnedders> | actually, I use Saf's bookmark bar |
| 23:22 | <gsnedders> | But that's it. |
| 23:22 | <Hixie> | my bookmarks are http://☺.damowmow.com/ |
| 23:22 | <gsnedders> | Eight items there, and that's it. |
| 23:22 | <Philip`> | I'm pretty sure I've bookmarked lots of useful things, but I never bother looking at them again |
| 23:22 | <Hixie> | because i use too many browsers to maintain a set offline |
| 23:22 | <Lachy> | I have a bookmarks folder filled with links to things like specs and other types of documentation and utilities. But mostly I just start typing the URI into the address bar and select from the list |
| 23:23 | <Lachy> | history search is awesome |
| 23:23 | <jwalden> | html5 is third on my list since depending on browser history it's the easiest way to get the spec :-) |
| 23:23 | <jwalden> | rfc 2616 is fifth |
| 23:23 | <gsnedders> | Lachy: agreed. That and Google is all I need :P |
| 23:23 | <gsnedders> | Hixie: Hey! My blog isn't on your blogroll! :P |
| 23:24 | <jwalden> | a search URL on Google that redirects probably infinitely which I haven't gotten around to reporting to Google is the top result, because I've not removed it from the saved set of tabs every time I open Firefox |
| 23:24 | <Philip`> | (Is it intentional that blogroll sounds like bogroll?) |
| 23:25 | <Philip`> | (I don't know if that's just a British term or something) |
| 23:25 | <Hixie> | jwalden: uri? |
| 23:25 | <jwalden> | sec |
| 23:25 | <Lachy> | for rfcs, I have have a special keyword set up so I just type "rfc ####" and it takes me to it |
| 23:25 | jwalden | has to ssh into a machine with the sessionstore.js file |
| 23:25 | gsnedders | just uses spotlight and has all the RFCs stored locally |
| 23:27 | <Lachy> | hixie, do you have a key for ☺ on your keyboard? |
| 23:27 | <Hixie> | Lachy: no |
| 23:28 | <Lachy> | ok. cause that's basically the only URI in my history that I can't get by typing the first few letters |
| 23:28 | <Hixie> | it's my home page |
| 23:28 | <Hixie> | you can also get to it by going to damowmow.com/portal and clicking the link at the top |
| 23:28 | <Lachy> | I normally just type http://damowmow.com/portal/ instead |
| 23:29 | <jwalden> | Hixie: so a mispaste suggests that the original URL I was hitting is part of a class of such URLs; <http://www.google.com/url?sa=t>; seems to be a minimal testcase for me |
| 23:29 | <jwalden> | Hixie: original URL was <http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwiki.mozilla.org%2FJavaScript%3ASpiderMonkey%3ACoding_Style&ei=jf9kR6C_EZKcerz80Us&usg=AFQjCNHvvFthlkDqpEGRurEs1FdnfpHWrw&sig2=vZBmzjP3UMGLgIr75kh4vQ>; |
| 23:29 | <Philip`> | Lachy: Opera 9.5 makes "xn" autocomplete to the smiley-face page |
| 23:30 | <Philip`> | (after having only ever entered the ☺ form into the address bar) |
| 23:30 | <Lachy> | maybe I should try using Opera one day |
| 23:30 | <Philip`> | so you shouldn't need a smiley key in order to get it from your history |
| 23:31 | <Lachy> | Firefox does that too |
| 23:31 | <Lachy> | but it doesn't show the smiley |
| 23:32 | <Philip`> | Hmm, Opera autocompletes from xn but not from ☺ |
| 23:32 | <Hixie> | jwalden: oh yeah, /url changed behaviour recently, and probably broke any bookmarks to it |
| 23:32 | <jwalden> | no smiley for com TLD, they don't do enough to prevent lookalike domain names |
| 23:32 | <Philip`> | Konqueror 4 autocompletes from both |
| 23:32 | <Hixie> | jwalden: that won't get fixed i don't think |
| 23:32 | <jwalden> | okay |
| 23:32 | <Hixie> | though i don't see why it's doing an infinite loop |
| 23:32 | <jwalden> | I got that from a search results page, let's see if I can still find it, tho |
| 23:33 | <Hixie> | i'll file a bug anyway |
| 23:33 | <Hixie> | when i get to work |
| 23:33 | <Hixie> | speaking of which |
| 23:33 | <Hixie> | i should go |
| 23:33 | <Hixie> | bbl |
| 23:34 | <Lachy> | jwalden, the smiley doesn't stay in the address bar for http://☺.lachy.id.au/ either |
| 23:34 | <jwalden> | Hixie: so visiting <http://www.google.com/search?q=non+sequitur+else+return&hl=en&safe=off&client=firefox-a&rls=org.mozilla:en-US:official&pwst=1&start=60&sa=N>;, I have "JavaScript:SpiderMonkey:Coding Style - MozillaWiki" several down the results list |
| 23:34 | <jwalden> | Hixie: and the link location for that is <http://www.google.com/url?sa=t&ct=res&cd=66&url=http%3A%2F%2Fwiki.mozilla.org%2FJavaScript%3ASpiderMonkey%3ACoding_Style&ei=ll0SSMOFNJPWerXhpJkC&usg=AFQjCNHvvFthlkDqpEGRurEs1FdnfpHWrw&sig2=07FhJu9UeXFs5cSCXO29Yw>;, which redirects infinitely |
| 23:35 | <jwalden> | so something's still generating the old format, I guess |
| 23:36 | <gavin_> | Lachy: .au isn't on the whitelist either |
| 23:36 | <Lachy> | why? |
| 23:36 | <jwalden> | yeah, what he said |
| 23:36 | <jwalden> | dunno why |
| 23:36 | <Lachy> | the auDA has very strict rules about registering domains. I'm sure they wouldn't let lookalikes through too easily |
| 23:37 | <gavin_> | because no one has added it :) |
| 23:37 | <gavin_> | you can file a bug and point to the policy |
| 23:37 | <gavin_> | see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=423974 |
| 23:38 | <jwalden> | http://www.mozilla.org/projects/security/tld-idn-policy-list.html |
| 23:38 | <Philip`> | Can't certain characters be whitelisted? ☺ isn't likely to be a look-alike for any serious domain |
| 23:38 | <Lachy> | Philip`, some users might confuse it with http://:-).lachy.id.au |
| 23:41 | <Lachy> | gavin_, jwalden, auda has lots of policies. I'm not sure what exactly to look for http://www.auda.org.au/policies/current-policies/ |
| 23:42 | <jwalden> | I tend not to worry about the whitelisting; that's a UI thing |
| 23:42 | Philip` | wonders if you can use the smiley face plus combining characters to make a series of smiley faces with funny hats |
| 23:42 | <jwalden> | except when it comes to things like <https://bugzilla.mozilla.org/show_bug.cgi?id=414090>; :-( |
| 23:54 | <Lachy> | the nearest I can find is a prohibition on misspellings of names. http://www.auda.org.au/policies/auda-2006-05/ |
| 23:54 | <Lachy> | it doesn't explicitly mention IDNs, but it's general enough that it would cover any characters used |