| 05:49 | <G0k> | Hixie: so what the status on server sent events? |
| 05:53 | <Hixie> | how do you mean? |
| 05:53 | <G0k> | about it being possibly removed? |
| 05:54 | <Hixie> | it hasn't seen much implementation from other browser vendors than opera, and it's redundant with other features |
| 05:54 | <Hixie> | so it might possibly be removed |
| 05:54 | <G0k> | which other feature makes it redundant? |
| 05:54 | <othermaciej> | we might implement it in WebKit |
| 05:54 | <othermaciej> | you could argue it is redundant with XMLHttpRequest |
| 05:55 | <Hixie> | it's redundant with networking and with multipart xmlhttprequest |
| 05:55 | <othermaciej> | (assuming it is spec'd clearly enough that you can rely on getting multiple responses for separate data chunks) |
| 05:55 | <othermaciej> | not even multipart |
| 05:55 | <othermaciej> | people use regular-type XHR for multiple server-sent messages over one connection |
| 05:56 | <Hixie> | true |
| 05:56 | <othermaciej> | but <event-source> is potentially a nice convenience |
| 05:56 | <G0k> | i have two concerns about it |
| 05:56 | <Hixie> | yeah, the question is should the platform have conveniences? or just the core platform features that can be used to implement the conveniences? |
| 05:57 | <G0k> | i think the DOM event metaphor is really strained |
| 05:57 | <Hixie> | if we do keep it, we'll certainly need to massively simplify it. it's way over-engineered right now. |
| 05:57 | <othermaciej> | it should have conveniences in cases where patterns are very commonly seen in library code |
| 05:57 | <G0k> | and it's impossible to implement backwardsly |
| 05:57 | <G0k> | yeah |
| 05:57 | <othermaciej> | thus the Selectors API |
| 05:57 | <othermaciej> | (and getElementsByClassName) |
| 05:57 | <Hixie> | yep |
| 05:58 | <Hixie> | maybe this is such a case |
| 05:58 | <Hixie> | maybe it isn't |
| 05:58 | <G0k> | hixie: what if we a) make it for Message events only and b) add a way to implement it based on slow download requests so that it can be emulated with XHR for older browsers? |
| 05:58 | <Hixie> | that's why it's marked as "may be removed". cos it may be removed. :-) |
| 05:59 | <G0k> | so like old browsers can add application/x-dom-event-not-a-stream to their Accept headers, and it will just end the connection after every event is sent |
| 05:59 | <Hixie> | G0k: (a) is easy; but i'm not sure i follow (b). If you have a solid proposal, feel free to mail it to the list for consideration. |
| 05:59 | <Hixie> | i wouldn't rely on Accept headers for anything |
| 05:59 | <Hixie> | but yeah |
| 06:00 | <G0k> | why not? |
| 06:00 | <Hixie> | that kind of stuff hasn't historically worked well |
| 06:01 | <G0k> | hm. i suppose we could do it the other way around, if it doesn't have the accept header for the event stream, the server would default to a non-streaming method |
| 06:03 | <Hixie> | i would recommend something that doesn't in any way involve accept or content-type headers working correctly |
| 06:04 | <Hixie> | if the web's history has taught us anything, it's that people don't understand or honour mime types. |
| 06:04 | <othermaciej> | G0k: you don't have to end the connection after every event to work with XHR |
| 06:04 | <G0k> | well even if the accept wasn't formed correctly, the worst thing that would happen is that it would degrade to slower behavior |
| 06:04 | <othermaciej> | G0k: I believe current-generation browsers could emulate server-sent events on top of XHR using the current HTML5 event stream format |
| 06:05 | <othermaciej> | (though I haven't actually tried it) |
| 06:05 | <G0k> | othermaciej: i've found the behavior of partial downloads kinda unpredictable though |
| 06:05 | <othermaciej> | the JS library folks are calling the persistent connection for messages from the server thing "COMET" |
| 06:06 | <othermaciej> | so probably a sensible thing to do would be to find what kind of API they offer as design input for a standards-track way of doing it |
| 06:06 | <Hixie> | COMET is just one implementataion, as i understand it |
| 06:06 | <G0k> | i think it's really critical to be able you can emulate this in older browsers |
| 06:06 | <othermaciej> | I thought COMET was the concept |
| 06:06 | <G0k> | i think comet is a big idea |
| 06:06 | <G0k> | yeah |
| 06:06 | <othermaciej> | http://en.wikipedia.org/wiki/Comet_(programming)#Browser_compatibility |
| 06:06 | <othermaciej> | here's the mechanisms people have used for it |
| 06:06 | <othermaciej> | but I dunno what kind of API is offered |
| 06:06 | <Hixie> | man people have got to stop making up new acronyms for stuff that already has names |
| 06:07 | <G0k> | i've seen many |
| 06:07 | <othermaciej> | wow, lots of info about WebKit in there |
| 06:07 | <othermaciej> | very educational |
| 06:08 | <G0k> | from my basic research, i think the most reliable implementations have used a "slow download with re-download" XHR or iframe method |
| 06:08 | <G0k> | the multipart thing would allow for constant connections, but only gecko really does that |
| 06:08 | <othermaciej> | streaming over a single connection works just as well |
| 06:09 | <othermaciej> | I'm not sure what is better about multipart |
| 06:09 | <othermaciej> | other than handling message boundaries inside the engine |
| 06:09 | <G0k> | i think that's the critical issue |
| 06:09 | <othermaciej> | it's not that hard to make up a protocol for message boundaries |
| 06:09 | <G0k> | i don't think any UAs really make guarantees about when they flush their buffers for XHR reads |
| 06:10 | <othermaciej> | neither WebKit nor Gecko will buffer indefinitely |
| 06:10 | <othermaciej> | I don't know about IE |
| 06:10 | <G0k> | no, but imagine a chat application |
| 06:10 | <othermaciej> | I assume the streaming XHR thing doesn't work in IE or people would use it |
| 06:10 | <G0k> | even if it's 15 seconds, that's bad |
| 06:11 | <G0k> | which is why people (meebo, for instance) use multiple requests |
| 06:11 | <othermaciej> | is it ever actually 15 seconds? |
| 06:11 | <othermaciej> | I don't actually know |
| 06:11 | <G0k> | i'm haven't benchmarked it |
| 06:12 | <G0k> | this wikipedia page seems to suggest that it never fires on webkit until at least 256 bytes are recieved |
| 06:12 | <othermaciej> | anyway it would be good for WebKit to support multipart/x-mixed-replace in XHR (I assume that is the kind people mean), but I am not entirely sure what correct behavior for that is supposed to be |
| 06:12 | <othermaciej> | I guess we'd have to reverse-engineer Gecko |
| 06:12 | <othermaciej> | G0k: I don't think that is true |
| 06:12 | <othermaciej> | older versions used to require some amount of data to be sent to prime the buffer initially |
| 06:13 | <othermaciej> | I think after that (and now right away) it will fire readystate 3 without a floor on bytes received |
| 06:13 | <othermaciej> | (could be wrong, but that's my recollection) |
| 06:13 | <G0k> | ok, but it's highly possible that opera and IE don't even do that |
| 06:14 | <G0k> | and i don't think the XHR specs even specify this |
| 06:14 | <G0k> | also imagine a proxy server |
| 06:14 | <G0k> | actually, don't, that makes no sense |
| 06:14 | <Hixie> | 58 tests done, 42 tests to go. |
| 06:14 | <Hixie> | more than half-way there! |
| 06:14 | <G0k> | woot |
| 06:15 | <othermaciej> | XHR specs don't specify this, but they could |
| 06:15 | <othermaciej> | used to be they didn't specify anything |
| 06:15 | <G0k> | ok but that won't make IE support it |
| 06:16 | <G0k> | i really really feel being able to emulate this kind of thing on old browsers is a splendid idea |
| 06:16 | <othermaciej> | x-mixed-replace is a pretty crappy wire protocol as far as message boundaries go |
| 06:16 | <G0k> | yeah |
| 06:17 | <G0k> | plus it makes server code potentially really complicated |
| 06:17 | <othermaciej> | really? seems no worse than any other server-sent message protocol |
| 06:18 | <othermaciej> | as far as impact on most of your server code |
| 06:18 | <othermaciej> | (presumably on some level the server has an API that says "post this message now" or something) |
| 06:19 | <G0k> | well yeah once you abstract that away |
| 06:19 | <G0k> | but now you have to set up boundaires |
| 06:20 | <G0k> | and escape your data appropriately |
| 06:22 | <othermaciej> | is there escaping? |
| 06:22 | <othermaciej> | I think you just need to make sure to pick a boundary string that won't appear in the message |
| 06:22 | <othermaciej> | which is what sucks |
| 06:22 | <othermaciej> | if there was escaping, you could let some abstraction layer pick the boundary and do escaping |
| 06:22 | <G0k> | yeah so how do you know that before you start sending |
| 06:23 | <G0k> | i mean in this particular case, i think the fact that boundaries start with --- and the dom event stuff doesn't makes it easier |
| 06:23 | <othermaciej> | I guess you can do "escaping" by making sure no line ever starts with -- |
| 06:26 | <G0k> | still, this doesn't help us for older UAs that don't support mixed |
| 06:27 | <othermaciej> | no new feature helps for older UAs |
| 06:28 | <G0k> | but i'm saying if we had a mode which used mulitple connections |
| 06:28 | <G0k> | that could emulate server sent events even on UAs which only support single part XHR |
| 06:29 | <othermaciej> | I think you'd be better off using the Htmlfile control in IE and streaming XHR in other browsers |
| 06:29 | <othermaciej> | if what you want to do is put a nicer API on top of existing UA functionality |
| 06:30 | <G0k> | what is the Htmlfile control? |
| 07:37 | <Hixie> | i want to test HTTP somehow in acid3 |
| 07:37 | <Hixie> | but i have no idea how |
| 07:37 | <Hixie> | i don't want to do anything fancy on the server side... |
| 07:59 | <jruderman> | Hixie: what aspect of HTTP? |
| 08:00 | <Hixie> | dunno |
| 08:00 | <jruderman> | Hixie: acid 2 tested browsers' recognition of 404 errors quite nicely, i hear ;) |
| 08:00 | <Hixie> | ooh, yeah, could test <object> and 404 stuff |
| 08:01 | <jruderman> | how about <object type> vs server-provided content-type? |
| 08:01 | <Hixie> | that one's controversial |
| 08:02 | <jruderman> | oh, you're trying to stay *away* from controversy? :P |
| 08:02 | <Hixie> | in acid tests? yeah, ideally |
| 08:03 | <Hixie> | acid tests are controversial enough as it is without them risking their credibility |
| 08:03 | <jruderman> | hehe, ok |
| 08:03 | <Dashiva> | They're supposed to be borderline useful, not purely spec nitpicking :) |
| 08:03 | <jruderman> | according to https://bugzilla.mozilla.org/show_bug.cgi?id=395110#c17 safari get the <object type> thing "wrong" |
| 08:03 | <Hixie> | yeah but html5 might make that "right" |
| 08:03 | <jruderman> | so i'm not surprised to hear that it's controversial |
| 08:03 | <Hixie> | it's unclear what's going to happen with that |
| 08:03 | <jruderman> | interesting |
| 08:04 | <Hixie> | html5 already says to ignore content-type for <script> |
| 08:04 | <Hixie> | and <img> has some thing where all image/* types are treated equivalently iirc |
| 08:05 | <Hixie> | content-type, in retrospect, is such a bad idea |
| 08:05 | <jruderman> | why is it a bad idea? |
| 08:05 | <Hixie> | so few people get it right |
| 08:05 | <Hixie> | it gets in the way of people more often than it helps |
| 08:06 | <Hixie> | doesn't really help the human race |
| 08:06 | <Hixie> | we shoudla done everything with unambiguous magic byte sequences |
| 08:33 | <othermaciej> | Hixie: it's hard to test http in any serious way without using XMLHttpRequest |
| 09:09 | <Hixie> | othermaciej: yeah |
| 09:14 | <Hixie> | oh jesus |
| 09:14 | <Hixie> | i try to catch a webkit bug and a gecko bug with one carefully crafted test, and IE7 responds by crashing. |
| 09:15 | <Hixie> | *sigh* |
| 09:16 | <Lachy> | are you trying to avoid including crash bugs in the acid test? |
| 09:16 | <Hixie> | yes |
| 09:16 | <Hixie> | pissing off the media is tactically bad |
| 09:16 | <Hixie> | and crashing a reporter's browser would piss him off |
| 09:16 | <Hixie> | :-) |
| 09:19 | <othermaciej> | Hixie: obviously you need to make pH 0 acid test of all crash bugs |
| 09:19 | <Hixie> | man that would be a bitch to write :-) |
| 09:19 | <Hixie> | so apparently it's only my copy that crashes |
| 09:20 | <Hixie> | i have two people who've tested IE7 on XP and it didn't crash |
| 09:21 | <Lachy> | oh nice, MS are disabling support for older MS Office formats. http://it.slashdot.org/article.pl?sid=08/01/01/137257 - Hooray for proprietary formats! :-) (too bad if you have some in your archive you need to read one day) |
| 09:22 | <othermaciej> | good thing we're not reading that through an article.xaml or article.swf url then |
| 09:22 | <Hixie> | the last test i added to acid3 shows a really weird bug in firefox |
| 09:22 | <Hixie> | check out the dot in the "i" of "Acid3" |
| 09:34 | <Lachy> | Hixie, is the support-a.png image supposed to be a cat? |
| 09:36 | Lachy | wonders if Hixie would ever use a picture of any other type of animal? |
| 09:37 | <Lachy> | gotta go, back soon |
| 09:41 | <Hixie> | heh |
| 09:41 | <Hixie> | support-a.png returns a 404 of a cat, yes |
| 09:53 | <Hixie> | right |
| 09:54 | <Hixie> | i worked around the IE crash |
| 09:54 | <Hixie> | it still shows the IE error messages |
| 09:54 | <Hixie> | oh wait i might be able to work around that too |
| 09:55 | <Hixie> | yes! |
| 09:55 | <Hixie> | haha! |
| 09:55 | <Hixie> | take that, silly crashing browser that i wasn't even trying to show a bug in! |
| 09:55 | <Hixie> | i managed to make it not crash or show errors without even using anything outside of DOM1 Core! |
| 09:55 | <Hixie> | and without doing anything unjustifiable! |
| 09:56 | <Hixie> | and it still shows the wacky rendering in firefox! |
| 09:56 | <Hixie> | 41 tests to go |
| 10:15 | <hsivonen> | Philip`: hmm. looks like the Xalan serializer is broken. :-( |
| 10:16 | <hsivonen> | Philip`: also, the Sun UTF-8 decoder is bogus for not catching CESU-8 |
| 10:22 | <hsivonen> | I wonder if there's somekind of project management theory on when it's worthwhile to write your own XML serializer instead of work around the bugs in someone else's |
| 10:40 | <hsivonen> | aargh. People should write UTF-8-only serializers. The UTF-8 output of the Xalan serializer is broken because it tries to be too smart about output encodings |
| 11:10 | <hsivonen> | http://java.sys-con.com/read/478303_2.htm |
| 11:11 | <hsivonen> | "HTML5 will eclipse XHTML" according to Microsoft Senior Evangelist |
| 11:11 | <Hixie> | didn't that happen already? |
| 11:23 | <hsivonen> | Philip`: https://issues.apache.org/jira/browse/XALANJ-2419 |
| 11:39 | <Philip`> | hsivonen: Fun |
| 11:53 | <hsivonen> | Philip`: I could turn my HTML5 serializer into a doctypeless namespaceless XML serializer with relative ease |
| 11:53 | <hsivonen> | Philip`: the problem is that to really replace the Xalan serializer, I'd need to write the code that reconstructs the namespace declarations |
| 11:54 | <hsivonen> | and it seems to me that the time it would take could be used for feature work |
| 11:58 | <Hixie> | 40 tests to go |
| 12:04 | <hsivonen> | so, should a filter that takes out extension namespaces before validating zap the tags or zap the subtree? |
| 12:05 | <hsivonen> | I'm inclined to say subtree, but I could argue why you'd want to zap just tags |
| 12:06 | <Philip`> | http://validator.w3.org/check?uri=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fchars.html&charset=iso-8859-1&output=soap12 |
| 12:07 | <Philip`> | Why is well-formedness so totally impossible to get right? |
| 12:08 | <hsivonen> | Philip`: fun. Are you planning on reporting the bug? |
| 12:09 | <Philip`> | hsivonen: I don't really care enough about getting it fixed to bother reporting it |
| 12:10 | Philip` | thinks someone should make an Apache filter which detects XML responses and tests for well-formedness and if there's a problem it emails the server owner |
| 12:20 | <hsivonen> | Philip`: reported |
| 12:27 | <zcorpan> | http://validator.nu/?doc=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fchars.html&out=xhtml |
| 12:31 | <hsivonen> | zcorpan: yeah, known bug. https://issues.apache.org/jira/browse/XALANJ-2419 |
| 12:43 | <Philip`> | hsivonen: Thanks |
| 12:43 | <Philip`> | (I should probably stop being so lazy...) |
| 13:05 | <krijnh> | Ping |
| 15:08 | <Philip`> | Evil plan: |
| 15:08 | <Philip`> | * Find a project which uses git |
| 15:08 | <Philip`> | * Commit something, and put U+FFFE in the commit message |
| 15:09 | <Philip`> | and then nobody can use gitweb any more, unless they use IE |
| 15:09 | <Philip`> | (git says "Warning: commit message does not conform to UTF-8." but it commits anyway) |
| 15:09 | <hdh> | probably put some dummy repo on repo.or.cz |
| 15:24 | <takkaria> | Philip`: why's that a good idea? |
| 15:26 | <Philip`> | takkaria: Evil plans aren't meant to be good ideas :-p |
| 15:39 | <kig> | MacDomeOut: re: tablet, the cheapest intuos 3 is $200, but maybe easier to find someone in vicinity with one.. |
| 15:44 | <zcorpan> | hsivonen: your xhtml 1.0 schema seems to allow <noscript> in inline contexts |
| 15:48 | <hsivonen> | zcorpan: did XHTML 1.0 ban that? |
| 15:48 | <zcorpan> | hsivonen: html4 and xhtml1 allows noscript in block contexts only |
| 15:48 | <hsivonen> | zcorpan: ok. thanks |
| 15:50 | <zcorpan> | <!ENTITY % Block "(%block; | form | %misc;)*"> ... <!ENTITY % misc "noscript | %misc.inline;"> |
| 15:50 | <hsivonen> | <script> works as inline, doesn't it? |
| 15:50 | <zcorpan> | yes |
| 15:51 | <zcorpan> | <!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*"> ... <!ENTITY % misc.inline "ins | del | script"> |
| 15:55 | <hsivonen> | zcorpan: fix deployed. thanks |
| 16:01 | <zcorpan> | hsivonen: <h1><noscript><p>... still validates for me |
| 16:02 | <hsivonen> | hmm |
| 16:41 | Philip` | wonders how best to implement X3D's <Text/> |
| 16:42 | <Philip`> | I guess I have to do it as a textured quad, probably using mozDrawText in Firefox and using drawImage(svg) in Opera, or something like that... |
| 16:44 | <kig> | unless you want to write a freetype font server and .... |
| 16:48 | <Philip`> | I'd like to avoid relying on a server, though I think I'll end up requiring one anyway so I can do cross-domain XHR :-( |
| 17:15 | <Philip`> | What is window.Text? (I can't find any documentation of it...) |
| 17:15 | <Philip`> | Oh, looks like http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1312295772 |
| 17:16 | <Philip`> | Doesn't sound very useful, so I'll overwrite it with my own global Text variable |
| 18:33 | <kig> | hohoo, bounding box scaling working. next is snap to original scale and shift-constrained rotate and scale |
| 18:33 | <Philip`> | Well, this would work better if texImage2DHTML didn't always crash when I use it |
| 18:34 | <kig> | ssss |
| 18:35 | <kig> | what is it supposed to do? |
| 18:35 | <Philip`> | It's supposed to not crash |
| 18:35 | <Philip`> | and, preferably, it should do some texture binding stuff |
| 18:35 | <Philip`> | (when given an image or canvas to convert into a GL texture) |
| 18:36 | <kig> | ah |
| 18:39 | <kig> | do you have the texture bound? |
| 18:40 | <kig> | since all texImage2DHTML seems to do is get the image surf data and call glTexImage2D with it |
| 18:41 | <Philip`> | I was stupid and forgot to call bindTexture; but now I am calling it and it still crashes :-( |
| 18:43 | <kig> | :I |
| 18:44 | Philip` | tries building a debug version, and hopes he has enough disk space |
| 18:45 | <kig> | paste a snippet? |
| 18:46 | <kig> | (not that crashing the browser as a failure mode is very nice) |
| 18:55 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cimg%20src%3Dhttp%3A%2F%2Fphilip.html5.org%2Ftests%2Fcanvas%2Fsuite%2Fimages%2Fred-16x16.png%20id%3Di%3E%3Ccanvas%20id%3Dc%3E%3C%2Fcanvas%3E%0D%0A%3Cscript%3E%0D%0Awindow.onload%20%3D%20function%20()%20%7B%0D%0A%20%20var%20gl%20%3D%20document.getElementById('c').getContext('moz-glweb20')%3B%0D%0A%20%20var%20ids%20%3D%20gl.genTextures(1)%3B%0D%0A%20%20gl.bindTexture(gl.T |
| 18:55 | <Philip`> | Oops, bit long |
| 18:55 | <Philip`> | http://tinyurl.com/28eceb |
| 19:04 | <kig> | that sure looks like it should work |
| 19:06 | <Philip`> | I was going to look at normal texturing after adding some primitive text, but I guess I'll have to give up on both of those ideas for now :-( |
| 19:21 | <Philip`> | Oh, great, now I get errors when compiling Mozilla on Vista because Vista guesses that nsinstall.exe is a program installer because it has "install" in its name, and so it requires admin privileges which it can't get when running on the command line and so it dies |
| 19:36 | <jruderman> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=410460 ;) |
| 19:40 | <gavin> | I filed that yesterday when Hixie was asking about it in #devs |
| 19:40 | <gavin> | he knows about it :) |
| 21:07 | <gsnedders> | hmmm. "ANSI" seems to be an alias for US-ASCII in the real world. |
| 21:26 | <gsnedders> | No, for windows-1252 |
| 21:27 | <gsnedders> | That can't be right :\ |
| 21:33 | <Hixie> | hsivonen: http://groups.google.com/group/google-caja-discuss/browse_thread/thread/712c772b93777a64/88dcb5f7799358af?hl=en&q=whatwg#88dcb5f7799358af (search for validator.nu) in case you didn't know |
| 21:51 | <hsivonen> | Hixie: interesting. I wasn't aware. thanks. (however, it isn't called libhtmlparser and it's under the MIT license, not MPL) |
| 21:53 | <Philip`> | (There's no version 1.5.1 either) |
| 22:34 | <Philip`> | Hmm, texImage2DHTML doesn't crash now that I've compiled it myself |
| 22:34 | <Philip`> | but gl.uniformi doesn't work because it has unimplemented code |
| 22:36 | <Philip`> | and the only way to use textures is by using uniformi |
| 23:04 | <webben> | Philip`: What are you actually making btw? A renderer that will take X3D input and produce a canvas rendering? |
| 23:04 | <webben> | (just curious) |
| 23:05 | <Philip`> | webben: Yes (using Firefox's/Opera's 3d canvas contexts) |
| 23:05 | <Philip`> | Well, it's not just producing a rendering - it does some animation and user-controlled camera movement and stuff |
| 23:05 | <webben> | I see. |
| 23:09 | <Philip`> | My idea is that X3D can't be implemented natively by browsers (because there would be approximately no interoperability, given how it's defined), so they have to implement something like OpenGL, but OpenGL is really painful to use for anything non-trivial, so a higher-level 3D engine is needed, and X3D is a vaguely sensible way of doing that |
| 23:19 | <othermaciej> | http://torgo-x.livejournal.com/1013176.html |
| 23:21 | Philip` | found some Netscape 3.0 floppy disks at home today |
| 23:21 | <Philip`> | but I think that's the oldest version I've used, except when intentionally searching for ancient versions |
| 23:27 | <othermaciej> | what I find interesting about that post is that netscape 0.9b pretty much can't browse the current web |
| 23:27 | <othermaciej> | and that the showstopper problems are mostly at the HTTP level |
| 23:28 | <Hixie> | the bus i'm on just totally ran a red light |
| 23:28 | <Hixie> | good times |
| 23:30 | <webben> | the current web works pretty bad in mosaic IIRC too. |
| 23:30 | <webben> | or at least whatever mosaic is available for Windows systems from evolt |
| 23:30 | <webben> | can't remember if the problems were HTTP-related though |
| 23:31 | webben | wonders if worldwideweb works at all |
| 23:32 | <othermaciej> | I dunno |
| 23:32 | <othermaciej> | the current web works pretty bad in Amaya |
| 23:32 | <othermaciej> | so I guess a browser doesn't have to be old to fail |
| 23:32 | <othermaciej> | but I don't think Amaya fails quite as badly as Netscape 0.9 |
| 23:33 | <Hixie> | amaya is a browser to the same extent that a hybrid SUV is a way to save on carbon emissions |
| 23:34 | <webben> | Well, Amaya can't render text properly or handle HTTPS, but I think it can handle ordinary HTTP in a vaguely similar way to other browsers. |
| 23:35 | <webben> | Though I probably shouldn't whinge about it's text rendering without trying the latest version. |
| 23:36 | <Philip`> | Hooray, now I've got text, though it's upside-down and repeated five times and squashed so there's lots of empty space |
| 23:37 | <webben> | Now that sounds like Amaya's text rendering ;) |
| 23:37 | <webben> | (well except maybe the upside-down bit) |
%20%7B%0D%0A%20%20var%20gl%20%3D%20document.getElementById('c').getContext('moz-glweb20')%3B%0D%0A%20%20var%20ids%20%3D%20gl.genTextures(1)%3B%0D%0A%20%20gl.bindTexture(gl.T){kind=link}