| 01:58 | <ezyang> | Hmm... curious. So it looks like a numeric entity for \r shows up as \r |
| 01:59 | <Hixie> | in the spec? |
| 02:00 | <ezyang> | oh no, it looks like I misread |
| 02:22 | <Hixie> | god i hate the gzip module on apache |
| 02:22 | <Hixie> | i can't get it to work when i want it to, and i can't get it to go away when i need no compression |
| 02:28 | <ezyang> | I cna't find the "support '+' prefixes in integers" edit in the HTML spec |
| 02:29 | <ezyang> | oh, that's because I'm in the wrong area of the spec |
| 02:32 | <Hixie> | SetEnv no-gzip 1 |
| 02:32 | <Hixie> | is what disables gzipping on apache 2.x |
| 02:32 | <Hixie> | good to know |
| 09:34 | <annevk4> | hmm |
| 09:34 | <GPHemsley> | agreed |
| 09:34 | <annevk4> | most of CSSOM View does not seem to take into account multiple boxes :/ |
| 13:29 | <Lachy> | annevk4, yt? |
| 13:30 | <Lachy> | or anyone familiar with the Web Databases spec? |
| 13:31 | <Lachy> | in the executeSql() method, I can't tell what is supposed to happen when the SQL statemen† contains fewer question marks than there are items in the arguments array. |
| 13:31 | <Lachy> | e..g transaction.executeSql("INSERT INTO t(id, label) VALUES (?, ?)", [2, "Two", "foo"], statementCallback, errorCallback); |
| 13:33 | <Lachy> | nevermind, I misread the spec |
| 14:07 | <Philip`> | http://www.microsoft.com/presspass/presskits/eu-msft/docs/Microsoft_Interoperability_Undertaking.doc |
| 14:07 | Philip` | notices potential irony in the file format |
| 14:07 | <Philip`> | "Internet Explorer, as from version 8, in its default settings, shall pass the Acid 2 web page as it exists today (available at www.webstandards.org/action/acid2/ on the date of entry into effect of this Undertaking, assuming that the current version does not undergo substantial revision)." |
| 14:07 | <Philip`> | and also "the conformance test suite provided by W3C (available at www.w3c.org) for the HTML 4.0 specification", and CSS 1.0, and CSS 2.1 |
| 14:07 | <Philip`> | Also "beginning on 31 March 2010, Microsoft shall make publicly available complete and accurate documentation of any variations or extensions it has made to the HTML 4.0, CSS 1.0, and CSS 2.1 specifications and to any other final approved web standards published by W3C (as “W3C Recommendations”), ECMA (as “Standards”), or ISO (as “International Standards”) as implemented by Internet Explorer." |
| 14:57 | <Dashiva> | Philip`: Is the compatability view default or not? |
| 14:58 | <Philip`> | Dashiva: Not for most sites |
| 15:57 | <palimpsest> | hi |
| 15:58 | <palimpsest> | i'm trying to parse a page that has a very, very deep tag tree |
| 15:59 | <palimpsest> | the parser.parse(document) call takes at least two minutes and maxes out my CPU |
| 15:59 | <gsnedders|work> | With what tree builder? |
| 15:59 | <palimpsest> | BeautifulSoup |
| 15:59 | <gsnedders|work> | That may well be the problem there. |
| 15:59 | <palimpsest> | hm |
| 16:00 | <gsnedders|work> | Try using cElementTree or lxml instead, and see how quick it is to parse |
| 16:00 | <palimpsest> | ok |
| 16:00 | <palimpsest> | is there a way to limit the depth of the constructed tree? |
| 16:01 | <gsnedders|work> | No |
| 16:02 | <palimpsest> | ok, thanks |
| 16:06 | <palimpsest> | any idea what it is about BeautifulSoup that's causing the problem? |
| 16:06 | <gsnedders|work> | No idea, it's a blind guess. But BeautifulSoup does generally suck. |
| 16:06 | <palimpsest> | there's existing code for traversing a BeautifulSoup tree I'd prefer to avoid rewriting |
| 16:06 | <palimpsest> | any way to convert between tree types? |
| 16:07 | <gsnedders|work> | Converting won't help, as you'll still have to build the BS one |
| 16:07 | <gsnedders|work> | (And the answer is no anyway) |
| 16:08 | <palimpsest> | sigh, k, thanks |
| 16:08 | Philip` | doesn't know why the BS treebuilder would take an unusually long time with deep trees, but hasn't looked at the code enough to know if it's plausible that it's its fault |
| 16:08 | <palimpsest> | the other parsers do seem to be much faster |
| 16:08 | <palimpsest> | http://rover.ebay.com/rover/1/711-53200-19255-0/1?campid=5336301508&customid=feed&toolid=10005&mpre=http%3A%2F%2Fcgi.ebay.com%2F20-coupons-Buy-1-Mountain-Dew-20oz-get-a-Vault-FREE_W0QQitemZ300332084204QQcmdZViewItemQQssPageNameZRSS%3AB%3ASRCH%3AUS%3A101 |
| 16:08 | <palimpsest> | is the page |
| 16:09 | <gsnedders|work> | heh. predicable. BS sucks. |
| 16:09 | <Philip`> | It might just be that the html5lib code that uses BS is broken, rather than being entirely BS's fault |
| 16:09 | <palimpsest> | oh, i was having the same problem with BeautifulSoup on it's own |
| 16:10 | <Philip`> | Oh, okay |
| 16:10 | <gsnedders|work> | Philip`: I think our BS code is more or less fine, minus bugs caused by working around BS bugs |
| 16:11 | <Philip`> | gsnedders|work: I wrote some of our BS code, so I don't necessarily agree it's fine :-) |
| 16:11 | <Philip`> | but it passed more tests than before I wrote that code |
| 16:11 | <Philip`> | which was good enough for me |
| 16:12 | <gsnedders|work> | Wow. That's a lot of nested font elements. |
| 16:12 | <palimpsest> | yeah. |
| 16:13 | <palimpsest> | i don't really care about them, i just don't want to get stuck parsing the page |
| 16:15 | <Philip`> | I like the bit where it goes </FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT><FONT size=4><P></P><P></P></FONT><!-- End Description --></FONT><FONT size=4><FONT size=5></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT></FONT> |
| 16:16 | <Philip`> | Of course the real problem is that it doesn't quote its attributes |
| 16:16 | <gsnedders|work> | Yeah, if it did that, we could parse it in no time. |
| 16:17 | takkaria | chortles |
| 16:19 | <palimpsest> | i tried preprocessing it with http://countergram.com/software/pytidylib (which was also not fast, but better) but it didn't help |
| 22:38 | <annevk2> | Hixie, I believe the old algorithm also changed UTF-16 to UTF-8 |
| 22:38 | <annevk2> | Hixie, that also seems gone |
| 22:38 | <Hixie> | don't tell me, tell them |
| 22:40 | <annevk2> | I actually did; I wasn't sure whether you were trying to be exhaustive |
| 22:41 | <annevk2> | (I wasn't, FWIW, but I did catch that) |
| 22:41 | <Hixie> | k |
| 22:41 | <Hixie> | heycam: yt? |
| 22:41 | <Hixie> | heycam: is there a way to override the class name of an interface? I have two HTMLCollection interfaces that are different but apparently need to both be HTMLCollection objects. |
| 22:42 | <Hixie> | not sure what should happen if you override HTMLCollection itself |
| 22:43 | <annevk2> | can't the implementation of the interface be different? |
| 22:44 | <Hixie> | the interface itself is different |
| 22:44 | <Hixie> | and in JS, the interfaces _are_ the implementations |
| 22:44 | <Hixie> | since they have prototypes |
| 22:59 | <annevk2> | not quite, we can have both static and a live NodeList |
| 23:01 | <othermaciej> | Hixie: I don't think it makes sense to have the same interface object for interfaces with different methods |
| 23:01 | <annevk2> | and if you change namedItem to always return an Object... |
| 23:01 | <Hixie> | othermaciej: no disagreement from me there |
| 23:02 | <othermaciej> | (I assume this is about having tags() appear on the "all" HTMLCollection but not other HTMLCollections) |
| 23:02 | <Hixie> | annevk2: yeah but the .item() method on the static one is the same as the .item() method on the live one, which isn't the case with these collections |
| 23:02 | <Hixie> | othermaciej: yes |
| 23:03 | <othermaciej> | I think the only sensible way to do it is to make HTMLAllCollection a derived interface, is there a reason that would be a compatibility issue? |
| 23:04 | <othermaciej> | (of course the other alternative is to just leave tags() on all HTMLCollections) |
| 23:05 | <Hixie> | right now i've done both. We have two interfaces, and .tags() is on both. |
| 23:06 | <Hixie> | (there are other differences) |
| 23:07 | <sicking> | Hixie, why have .tags() on all HTMLCollections? |
| 23:07 | <Hixie> | because most browsers have it on all HTMLCollection objects |
| 23:07 | <Hixie> | see the mail i just sent to the list |
| 23:11 | <othermaciej> | Hixie: is the return of namedItem the other difference? |
| 23:11 | <othermaciej> | Hixie: I can imagine it might be a problem for HTMLCollection and HTMLAllCollection to have no inheritence relationship at all |
| 23:11 | <Hixie> | and the implementation of .namedItem, yeah |
| 23:11 | <Hixie> | why? |
| 23:11 | <Hixie> | the other collection interfaces have no relationship either |
| 23:11 | <Hixie> | there's five of them at this point |
| 23:11 | <Hixie> | they're all basically the same with weird minor differences |
| 23:12 | <othermaciej> | I don't know that it is a problem for sure, but if someone wants to prototype-hack HTMLCollection to add or modify a method, it won't work on the unrelated types of collection |
| 23:12 | <Hixie> | correct |
| 23:12 | <Hixie> | i don't see any way around that given that the prototypes would have different .namedItem()s anyway |
| 23:12 | <othermaciej> | so if that works in browsers currently, it could be a compat issue |
| 23:12 | <Hixie> | i guess we'll find out |
| 23:13 | <othermaciej> | you could just make namedItem() return Object and not worry about the fact that for some collections it's a more specific type |
| 23:13 | <Hixie> | the implementation is still different |
| 23:13 | <Hixie> | so the prototype needs to be different |
| 23:13 | <othermaciej> | that's irrelevant to the interface |
| 23:14 | <Hixie> | not in JS? |
| 23:14 | <othermaciej> | the prototype doesn't need to be different |
| 23:14 | <othermaciej> | we can have a single JS wrapper that can wrap multiple underlying C++ classes with different behavior |
| 23:14 | <Hixie> | so there's only one namedItem() implementation, and it just happens to act very differently in different contexts? |
| 23:14 | <othermaciej> | the JS method just needs to call a C++ virtual method |
| 23:14 | <Hixie> | freaky |
| 23:21 | <Hixie> | i'm thinking of adding an event to WebSocket that fires when the buffers are filling too fast |
| 23:21 | <Hixie> | what should i call it? |
| 23:21 | <Hixie> | websocket.onoverflow ? |
| 23:22 | <Hixie> | websocket.onthrottle ? |
| 23:25 | <Hixie> | websocket.on... ? |
| 23:26 | <franksalim> | Hixie, the send buffer? or both buffers? the recv buffer must be taken care of by the underlying network layer, right? |
| 23:26 | <Hixie> | send |
| 23:28 | <ap> | Hixie: what's the semantics of this proposed event? does it fire from within send() that will fail? |
| 23:28 | <Hixie> | it fires asynchronously whenever the user agent feels like it (when the UA is in danger of hitting some internal limit) |
| 23:29 | <Hixie> | unless you have a better idea :-) |
| 23:30 | <ap> | Hixie: I still think that there needs to be an indication when send() fails |
| 23:30 | <Hixie> | you don't know when send fails |
| 23:31 | <ap> | Hixie: fails to take the data in its queue. sure you know that |
| 23:31 | <Hixie> | "take the data in its queue |
| 23:31 | <Hixie> | "? |
| 23:31 | <ap> | Hixie: here's what TCP guarantees: |
| 23:31 | <Hixie> | if you hit a hardware limitation, then you can do whatever you like |
| 23:31 | <ap> | Hixie: once you call send(), and it returns success |
| 23:32 | <ap> | Hixie: it means that either the data will be delivered to the other side |
| 23:32 | <ap> | Hixie: or no more data will be delivered to the other side over this connection |
| 23:32 | <Hixie> | no, it doesn't, except for some definition of "other side" that is not really practically useful to the author. |
| 23:33 | <ap> | Hixie: huh? |
| 23:33 | <Hixie> | what matters is whether the application level on the other side dealt with the data, and the only way you can know that is an acknowledgement. |
| 23:33 | <ap> | Hixie: I thought I explained it in detail in e-mail :( |
| 23:33 | <Hixie> | you can't know from TCP whether the server on the other side is still alive or has had some sort of crash or is spilling all its data on the floor or whatever. |
| 23:34 | <ap> | Hixie: repeating it again, it means that "either the data will be delivered to the other side, or no more data will be delivered to the other side over this connection" |
| 23:34 | <Hixie> | but that's not interesting information |
| 23:34 | <ap> | Hixie: that may sounds subtle, but it makes all the difference between TCP and UDP |
| 23:35 | <Hixie> | i understand the difference between TCP and UDP :-) |
| 23:35 | <ap> | Hixie: with this guarantee, you can do simple app-level acks |
| 23:35 | <Hixie> | sure |
| 23:35 | <ap> | Hixie: without it, you need much more complicated mechanisms for acks |
| 23:35 | <Hixie> | we already expose "the connection closed" |
| 23:36 | <Hixie> | i don't really see what you are proposing |
| 23:36 | <ap> | Hixie: what I'm saying is that there is absolutely no reason to provide UDP-level reliability when the underlying protocol is TCP |
| 23:36 | <Hixie> | ok... we're not doing that |
| 23:36 | <Hixie> | so where's the problem? |
| 23:37 | <ap> | Hixie: that's actually exactly what the spec provides now (well, except that it still guarantees ordering) |
| 23:37 | <Hixie> | how so? |
| 23:37 | <ap> | Hixie: if you call send() several times, and you get an ACK for the last, you cannot be sure that all the data arrived to the other side |
| 23:37 | <Hixie> | you can't drop packets in the middle and keep sending them |
| 23:38 | <Hixie> | how not? |
| 23:38 | <Hixie> | if that's so, there's an error in the spec |
| 23:38 | <Hixie> | what text did i screw up? |
| 23:38 | <ap> | Hixie: where does the spec say that once packets are dropped, the connection is closed? |
| 23:38 | <Hixie> | you're not allowed to drop packets at all. |
| 23:39 | <ap> | Hixie: oh, do you mean that the current text suggests filling up RAM until it ends? |
| 23:39 | <Hixie> | the current spec says that when you call send(), you have to send the bytes. |
| 23:39 | <Hixie> | it doesn't say how exactly |
| 23:39 | <Hixie> | they just have to be sent |
| 23:39 | <Hixie> | there's no permission to not send |
| 23:40 | <Hixie> | i can add a line saying "if you can't send, you have to close" if you like |
| 23:40 | <ap> | Hixie: neither sounds like useful behavior |
| 23:40 | <franksalim> | so there is no notion of a send failing |
| 23:40 | <Hixie> | ap: neither what? |
| 23:40 | <Hixie> | franksalim: not currently |
| 23:40 | <franksalim> | if you add a throttling event, there would have to still be a way to indicate that subsequent calls to send failed |
| 23:40 | <ap> | Hixie: neither filling up the RAM or closing at UA's discretion |
| 23:41 | <Hixie> | ap: what would you like the spec to say? |
| 23:41 | <ap> | Hixie: as indicated in the mailing list, I like Jeremy Orlow's proposal |
| 23:42 | <ap> | Hixie: an overflow event that is sent at UA's discretions sounds helpful, too |
| 23:42 | <Hixie> | you want send() to throw an exception when the TCP layer failed to successfully send the packet to the other side? |
| 23:42 | <ap> | Hixie: it's just no substitute |
| 23:43 | <Hixie> | that's what he suggested, but as far as i can tell it's impossible to implement, since send() has to be async. |
| 23:43 | <ap> | Hixie: actually not, that's not what he suggested |
| 23:43 | <Hixie> | ok, so what are you and he proposing, since i misunderstood what he suggested? |
| 23:44 | <ap> | Hixie: the suggestion is to raise an event when UA no longer wants to buffer the data in its queue (in practice, the buffer will be quite small, to allow for quick adaptation to network conditions) |
| 23:44 | <Hixie> | (that's definitely not what he suggested, but ok) |
| 23:44 | <ap> | Hixie: raqise an exception, sorry |
| 23:45 | <Hixie> | so you want send() to throw an exception (but leave the connection open) if the buffer is full? |
| 23:45 | <ap> | btw, quoting the suggestion, "Maybe the right behavior is to buffer in user-space (like Maciej explained) up until a limit (left up to the UA) and then anything beyond that results in an exception." |
| 23:45 | <ap> | Hixie: yes |
| 23:45 | <Hixie> | wouldn't that mean send() could arbitrarily and randomly fire exceptions? that seems like a _really_ bad idea |
| 23:45 | <Hixie> | and would effectively give you UDP-like behaviour |
| 23:46 | <ap> | Hixie: I don't agree with either statement (neither that it's bad, nor that it's somehow related to UDP-like behavior) |
| 23:46 | <ap> | Hixie: returning a boolean result would be as good as firing an exception in my eyes, btw |
| 23:47 | annevk2 | doesn't like getAsBinary and getAsBase64 |
| 23:47 | <Hixie> | it's bad for the same reason that we are avoiding firing an exception if you call send() on a closed WebSocket |
| 23:47 | <ap> | ok, let it be a boolean return value. there just needs to be a clear indication that the data passed to send() is dropped on the floor |
| 23:47 | <Hixie> | and it's UDP-like because it means that if you are calling send() on a timer at roughly the rate that you can send, then a random subset of the data will be sent, and the rest will be dropped on the floor. |
| 23:48 | <Hixie> | which, as you said earlier, is really bad |
| 23:48 | <ap> | Hixie: to determine the rate that you can send, one needs guidance |
| 23:49 | <Hixie> | sure, so we have the overflow event, which you can use to back off |
| 23:49 | <ap> | Hixie: back off by how much? |
| 23:49 | <Hixie> | (should probably be "willsoonoverflow" or something) |
| 23:49 | <Hixie> | who knows |
| 23:49 | <Hixie> | a boolean won't tell you either |
| 23:49 | <franksalim> | what happens when it actually overflows? |
| 23:49 | <ap> | Hixie: there are well established flow control protocols that work with "the boolean" |
| 23:49 | <franksalim> | exception? binary value? |
| 23:49 | <Hixie> | franksalim: i propose to make the connection close |
| 23:50 | <ap> | Hixie: like, every streaming protocol that works over TCP can adapt when send() fails |
| 23:50 | <Hixie> | ap: yeah, but they're all designed for experts |
| 23:50 | <Hixie> | ap: nobody except the experts are going to be checking for a return value from send(), realistically speaking |
| 23:50 | <Hixie> | ap: (they're also not going to be checking for an event) |
| 23:51 | <ap> | Hixie: with 128K or so buffered in the UA, non-experts will still be able to ignore the complexities, and control their toy trains |
| 23:51 | <Hixie> | i'm happy to make the event provide more information |
| 23:51 | <ap> | Hixie: you're now basically asking experts to come up with new flow control protocols, and non-experts will still not get decent streaming behavior |
| 23:52 | <annevk2> | what's the problem with the UA buffering all calls to send() somehow? |
| 23:52 | <franksalim> | annevk2, i think all of these proposed behaviors involve doing some amount of buffering |
| 23:52 | <ap> | annevk2: the data will never get to the other side if it's sent faster than the network can transmit it |
| 23:52 | <Hixie> | ap: i would be ok with returning a number from send() which is how much more data can be buffered, and then failing the connection when you go over the limit |
| 23:52 | <franksalim> | but they differ in what to do when a buffer fills |
| 23:53 | <ap> | Hixie: that sounds good to me, but it is not implementable |
| 23:53 | <franksalim> | why fail the connection when you could indicate failure of that particular call to send? |
| 23:53 | <annevk2> | ap, the UA can control how fast it is being sent |
| 23:53 | <Hixie> | ap: which is similar to what you're suggesting, except that going over (returning false) is fatal |
| 23:53 | <Hixie> | ap: why not? |
| 23:53 | <ap> | annevk2: by blocking send() until the queue is free? we agreed to never block |
| 23:53 | <Hixie> | franksalim: because people are going to ignore this data, and we don't want to make this UDP-like |
| 23:54 | <annevk2> | ap, it can queue up in the local RAM |
| 23:54 | <ap> | Hixie: hmm, maybe it can be implemented, let me think |
| 23:54 | <Hixie> | annevk2: if you're calling send() faster than the network can handle, you'll eventually run out of RAM |
| 23:54 | <annevk2> | ap, and when there's OOM it's just like any other platform implementation |
| 23:54 | <franksalim> | there are many ways for a javascript application to eat arbitrarily large amounts of RAM if the author is careless or malicious |
| 23:55 | <Hixie> | i'm rather with anne on this to be honest |
| 23:55 | <annevk2> | with implementation I meant limitation, sorry |
| 23:57 | <ap> | annevk2: e.g. if you're sending a video stream from a capture device, there is no good in filling up RAM until OOM |
| 23:57 | <ap> | annevk2: you want to be notified quickly, and to downscale your video |
| 23:57 | <Hixie> | we don't support sending a video stream |
| 23:58 | <Hixie> | if that's the use case, we can fix this in v2 |
| 23:58 | <ap> | Hixie: why don't we? |
| 23:58 | <annevk2> | I was just about to say that for specific types of data (e.g. files from the local disk) we should let send() accept dedicated types (e.g. FileData) and let the UA handle the specifics |
| 23:58 | <ap> | Hixie: what about an audio stream? |
| 23:58 | <annevk2> | it just handles text |
| 23:58 | <Hixie> | ap: because we don't have any of the building blocks for that yet |
| 23:59 | <ap> | Hixie: what about data for/from SETI@home? |
| 23:59 | <Hixie> | ap: we don't have binary data, we don't have stream interfaces, we don't have audio or video hardware access |
| 23:59 | <ap> | Hixie: or any other programmatically generated data stream? |
| 23:59 | <Hixie> | ap: SETI@home is rate-limited by the server |