| 00:08 | <yuhong_> | http://my.opera.com/ODIN/blog/2011/03/30/improving-interoperability-the-story-of-a-bug |
| 00:08 | <yuhong_> | Fortunately Opera lets you reparse the broken page as HTML> |
| 00:08 | <yuhong_> | Fortunately Opera lets you reparse the broken page as HTML. |
| 00:38 | <chriseppstein> | TabAtkins: yt? |
| 00:39 | <TabAtkins> | chriseppstein: Yo. |
| 00:39 | <chriseppstein> | hi |
| 00:39 | <chriseppstein> | am I crazy or did radial gradients used to accept an angle |
| 00:39 | <TabAtkins> | They did. I removed it because it was kinda useless. |
| 00:39 | <chriseppstein> | whew |
| 00:39 | <chriseppstein> | ok |
| 00:40 | <chriseppstein> | i'll take that out of my code then |
| 02:07 | <TabAtkins> | Yay, I built a parser for the UA stylesheet in the Lists module (so I could do a transformation to all the rules). Not only did it work, but it uncovered a bunch of CSS errors in the stylesheet. |
| 03:31 | <MikeSmith> | hmm |
| 03:31 | <MikeSmith> | http://tools.ietf.org/html/draft-pbryan-json-patch-00 |
| 03:32 | <MikeSmith> | "A JSON Media Type for Describing Partial Modifications to JSON Documents" |
| 03:39 | <heycam> | MikeSmith, reminds me of REX |
| 03:39 | <heycam> | (for XML) |
| 03:42 | <MikeSmith> | heycam: ah yes, REX |
| 03:42 | <MikeSmith> | I hope this works out better |
| 03:43 | <heycam> | yeah.. |
| 03:52 | <MikeSmith_> | Gecko already enables filter effects in HTML, right? |
| 03:52 | <MikeSmith_> | https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html stuff I mean |
| 03:57 | <heycam> | MikeSmith, I believe so |
| 03:57 | <MikeSmith> | cool |
| 03:58 | <MikeSmith> | heycam: btw, did plh bug you recently about WebIDL |
| 03:58 | <MikeSmith> | with regard to the Selectors API draft? |
| 03:59 | <heycam> | MikeSmith, yeah he did |
| 03:59 | <MikeSmith> | ok |
| 04:00 | <heycam> | Selectors API doesn't make terribly heavy use of Web IDL, so if the timing is such that the normative dependency has to be removed, and we need to include just a line or two about the relevant requirements (like null converting to string or whatever), then that's fine, we can add the dependency back in later |
| 04:00 | <MikeSmith> | oh |
| 04:00 | <MikeSmith> | that sounds reasonable |
| 04:02 | <MikeSmith> | actually what would be more reasonable going forward is that we allow recs to have normative dependencies on non-rec drafts, and we update them later if we need to (if the dependency changes in some way that requires it) |
| 04:03 | <MikeSmith> | the W3C process doc does not explicitly prohibit that, as far as I can tell |
| 04:03 | <heycam> | yeah. many of the requirements from web idl aren't important in the context of selectors api in particular. |
| 04:03 | <MikeSmith> | yeah |
| 04:03 | <heycam> | and browsers are likely going to implement the web idl requirements all at once in their binding generation code, not per spec |
| 04:04 | <MikeSmith> | ok |
| 04:04 | <heycam> | so gating selectors api on the exact requirements for, say, prototype chains in web idl doesn't make much sense to me |
| 04:05 | <MikeSmith> | yep |
| 04:05 | <MikeSmith> | we really should just evaluate spec-dependency issues case-by-case |
| 04:06 | <MikeSmith> | there are cases where we really know it matters |
| 04:06 | <MikeSmith> | like the WebSocket protocol |
| 04:07 | <MikeSmith> | but there are a whole lot more where it's not really an issue |
| 04:07 | <heycam> | yeah |
| 04:45 | <jacobolus> | Hixie: I didn't show you this thing yet did I? http://www.hcs.harvard.edu/~jrus/colortheory/javascript/colorpicker.html |
| 04:46 | <jacobolus> | [back on the subject of color spaces from a bit ago] |
| 04:46 | <jacobolus> | [also note, this is an in-progress thing, not expected to look much like this in its final form; still a lot of parts to build] |
| 04:56 | <yuhong_> | "he left the building" Note that I read the whatwg IRC logs a lot. |
| 04:57 | <yuhong_> | And yea, without any XSS filter in most cases you are going to be exploited whether you use XHTML or not. |
| 04:57 | <yuhong_> | But most XSS filters are not free of bugs. |
| 05:00 | <yuhong_> | And evasion tactics. |
| 06:22 | <jacobolus> | oh whoops, network died just as I was sending before; not sure what went through |
| 06:22 | <jacobolus> | Hixie: I didn't show you this thing yet did I? http://www.hcs.harvard.edu/~jrus/colortheory/javascript/colorpicker.html |
| 06:22 | <jacobolus> | [back on the subject of color spaces from a bit ago] |
| 06:22 | <jacobolus> | [also note, this is an in-progress thing, not expected to look much like this in its final form; still a lot of parts to build] |
| 06:29 | <Hixie> | jacobolus: funky |
| 06:29 | <Hixie> | jacobolus: i ended up doing a heuristic that works ok, fwiw |
| 06:30 | <Hixie> | jacobolus: i'll probably blog it at some point |
| 06:30 | <Hixie> | in other news, how the heck do you get a mobile web browser to actually follow the specs and not lie about its window width, etc? |
| 06:30 | <jacobolus> | [this thing will be less funky (or maybe just as funky but more useful) in the near future hopefully |
| 06:30 | <jacobolus> | ] |
| 06:30 | <jacobolus> | mobile browsers lie about their width? |
| 06:30 | <jacobolus> | why? |
| 06:31 | <Hixie> | so that normal css works ok |
| 06:31 | <jacobolus> | can you make that part of the next ACID test? :) |
| 06:31 | <Hixie> | but when you're trying to target them it is really annoying |
| 06:31 | <Hixie> | ok looks like android's browser just ignores @media handheld altogether |
| 06:46 | <Hixie> | christ this browser is buggy |
| 06:50 | <Hixie> | ah screw it |
| 06:50 | Hixie | sticks in a name=viewport meta thingy as a workaround |
| 06:51 | <hsivonen> | Hixie: the Android default browser is the new IE6 |
| 06:51 | <Hixie> | are there browsers that _don't_ screw this up? |
| 06:52 | <hsivonen> | You need <meta name="viewport" content="width=device-width, initial-scale=1"> to signal that you really mean what you say |
| 06:52 | <Hixie> | well you only need width=device-width, but yes |
| 06:53 | <Hixie> | but are there browsers that don't need this? |
| 06:53 | <hsivonen> | Opera 8 maybe? |
| 06:53 | <hsivonen> | dunno |
| 06:53 | <Hixie> | your analogy with IE6 implied the other browsers were doing ok |
| 06:53 | <Hixie> | but to my knowledge they all suck |
| 06:54 | <hsivonen> | Hixie: I'm rather convinced that the Android browser sucks more on teh whole |
| 06:54 | <hsivonen> | Hixie: also, I believe that the browsers are doing here what's the most Web-compatible thing to do |
| 06:54 | <hsivonen> | being Web-compatible isn't sucking |
| 06:54 | <hsivonen> | Hixie: Support Existing Content! |
| 06:55 | <Hixie> | i don't mind supporting existing content, but when i have media queries and so forth, or when i have an explicit media=handheld, just follow the damn specs |
| 06:55 | <hsivonen> | Hixie: media=handheld is for crappy browsers that predate even Opera 8 |
| 06:55 | <Hixie> | or at least fix the specs to describe what you do |
| 06:56 | <Hixie> | not according to the specs |
| 06:56 | <hsivonen> | Hixie: IMO the CSS WG should get rid of media=handled, because it has been poisoned |
| 06:56 | <Hixie> | if they did, i would not be complaining about browsers ignoring it |
| 06:57 | <Hixie> | my point is just that the specs and the browsers should match |
| 06:57 | <Hixie> | so that i can have a hope in hell of getting the result i want |
| 06:57 | <hsivonen> | Hixie: maybe you should write an email to www-style |
| 06:57 | <Hixie> | i'll let TabAtkins take care of it |
| 06:57 | <Hixie> | :-) |
| 06:58 | <Hixie> | man, position:fixed and background-position:fixed are a mess too |
| 06:59 | <Hixie> | aren't these things running like GHz processors? |
| 06:59 | <Hixie> | i had 486s that could do scrolling of multiple independent layers |
| 07:04 | <hsivonen> | Hixie: they had more suitable UI for selecting which layer to scroll |
| 07:05 | <Hixie> | how do you mean? |
| 07:10 | <hsivonen> | Hixie: you 486 had scrollbars and a pointing device precise enough to hit a scroll bar |
| 07:13 | <Hixie> | so? |
| 07:13 | <Hixie> | my phone has a whole screen i can scroll with my finger |
| 07:13 | <Hixie> | where's the problem here |
| 09:22 | <beowulf> | on android, adding the device-width viewport thingy works most of the time to get a correct innerWidth, but sometimes you also need to move the viewport as well |
| 09:53 | <jgraham> | Hah jslint uses spans inside table cells as checkboxes |
| 09:53 | <jgraham> | That is so full of fail |
| 09:53 | <jgraham> | I mean they even look ugly compared to normal checkboxes |
| 09:54 | <hsivonen> | jgraham: how dare you question the Good Parts |
| 09:55 | <jgraham> | Apparently HTML: The Good Parts wouldn't include |
| 09:55 | <jgraham> | media independence |
| 09:57 | <Rik`> | jslint is already dead btw |
| 09:58 | <jgraham> | In what sense? |
| 09:58 | <Rik`> | http://jshint.com/ |
| 09:58 | <Rik`> | more flexible for your own needs instead of doing what crockford believes right |
| 09:59 | <hsivonen> | Rik`: is it an independent codebase or a fork of jslint? |
| 09:59 | <Rik`> | a fork |
| 09:59 | <Rik`> | see at the bottom |
| 10:00 | <Rik`> | http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/ |
| 10:00 | <hsivonen> | Rik`: ok |
| 10:00 | <jgraham> | I thoght jslint was All Rights Reserved |
| 10:01 | <jgraham> | Oh no it's just the webpage that says that |
| 10:01 | <hsivonen> | jgraham: I thought it had Crockford's special "Good not Evil" license |
| 10:02 | <jgraham> | Yeah, it has the scary license |
| 10:02 | <hsivonen> | let's see if he decides jshint is "evil" |
| 10:02 | <hsivonen> | Rik`: “move ‘var’ declarations to the top of the function” Wow. |
| 10:03 | <jgraham> | Anyway jshint is obviously a failure because it can't lead a double life as the One True Javascript Benchmark |
| 10:04 | <Rik`> | wow, Apple geolocation file makes the top headline on http://www.lemonde.fr/ |
| 10:07 | <hsivonen> | In the French context, I'd be more worried about the state's hostility towards technical designs that make surveillance harder. |
| 10:08 | <hsivonen> | exhibit A: GSM. exhibit B: the bill about that effectively requires unhashed passwords |
| 10:09 | <Rik`> | yeah the amount security and surveillance laws in the last 9 years is really scary |
| 10:15 | <othermaciej> | wow, Crockford is mean to his users |
| 10:15 | <othermaciej> | (from reading stuff linked from that post) |
| 11:30 | <hsivonen> | jgraham: the output from hg push to the W3C test repo just managed to scare me quite a bit |
| 11:31 | <hsivonen> | what's the deal with getting lines like |
| 11:31 | <jgraham> | hsivonen: In what way? |
| 11:31 | <hsivonen> | remote: html/tests/submission/PhilipTaylor/tools/canvas/gentest.py |
| 11:31 | <hsivonen> | remote: html/tests/submission/PhilipTaylor/tools/canvas/spec.yaml |
| 11:31 | <hsivonen> | when pushing something unrelated |
| 11:31 | <jgraham> | hsivonen: I'm not sure |
| 11:31 | <hsivonen> | jgraham: it made it look like I had overwritten everything by accident |
| 11:31 | <jgraham> | I saw that yesterday but couldn't see that I had done anything bad |
| 11:32 | <jgraham> | It didn't happen a few weeks back |
| 11:32 | <hsivonen> | jgraham: thanks for the insertAdjacentHTML test conversion |
| 11:32 | <hsivonen> | jgraham: I tweaked it a little bit, created an XHTML variant and pushed |
| 11:32 | <jgraham> | Maybe it is from one of the commit hooks |
| 11:32 | <jgraham> | hsivonen: np |
| 11:32 | <jgraham> | Thanks for pushing |
| 11:32 | <hsivonen> | so now I'm supposed to send email to the list, I gather |
| 11:33 | <jgraham> | Yeah, something like that |
| 11:41 | <hsivonen> | jgraham: do I need to request review from a particular person, or will stuff just happen now that I've thrown the tests over the wall? |
| 11:41 | <jgraham> | hsivonen: In theory magic will now happen |
| 11:41 | <hsivonen> | jgraham: cool |
| 11:42 | <jgraham> | In practice the review system is somewhat dysfunctional |
| 11:42 | <hsivonen> | :-( |
| 11:42 | <jgraham> | Sad face indeed |
| 11:44 | <jgraham> | Basically the problem is that not many people are paying attention, doing review is not very interesting, and no one gets paid to do it |
| 11:45 | <hsivonen> | I had thought Microsoft was paying krisk to do it |
| 11:45 | <jgraham> | I don't really know how to solve any of that, but I would like it if we could solve the technical problems like "doing review by email sucks" |
| 11:45 | <hsivonen> | what's the MANIFEST about under Ms2ger's dir? |
| 11:45 | <hsivonen> | do I need a MANIFEST? |
| 11:46 | <jgraham> | I don't know exactly what proportion of his time krisk gets to spend on HTMLWG testsuite stuff or what he does in that time |
| 11:46 | <jgraham> | He does, admittedly, do some review and spends some time doing the busywork that the whole approved/submitted system needs |
| 11:47 | <jgraham> | hsivonen: No. It is needed by the harness to pick up tests |
| 11:48 | <jgraham> | But I think someone else will create it once the tests get approved |
| 11:48 | <jgraham> | (we should probably change the system so that you *do* have to submit a manifest file. But that isn't the current system) |
| 11:52 | <jgraham> | hsivonen: I can't review since I touched the tests, but I expect it will be suggested that you remove the bugzilla references |
| 11:53 | <jgraham> | I could be wrong though |
| 12:40 | <hsivonen> | is http://crockford.com/javascript/performance.html an accidental or intentional troll? |
| 12:45 | <jgraham> | The cynical view is that it is an attempt to advertise JSLint by getting it included in benchmarks |
| 12:47 | <espadrine> | Well, everybody knows that javascript is mainly used for javascript parsing, so those benchmarks are important. |
| 12:47 | <espadrine> | Plus, they explain very specifically how they are managed, with a clear understanding of statistics. |
| 12:50 | espadrine | wonders how we can get clear IE javascript measuring without a standalone executable. |
| 12:50 | <Philip`> | JS is probably used for parsing more than it's used for e.g. raytracing |
| 12:51 | <Philip`> | so parsing seems as useful a thing to include in benchmark suites as what they already include |
| 12:52 | <Philip`> | (Extrapolating a single figure to proclaim overall "JavaScript performance" is not useful, though) |
| 12:53 | <Philip`> | (and failing to provide an easy way to reproduce the figures makes it impossible to trust at all) |
| 12:55 | <espadrine> | I checked, the explanation of how he got the numbers is not hidden in the page's source code. |
| 12:57 | <Philip`> | There's no doctype in the page's source code either, which doesn't inspire great trust |
| 12:58 | <Philip`> | (Does IE still use its old zillion-times-slower JS engine in quirks mode?) |
| 12:59 | <gsnedders> | Philip`: (No. Chakra's behaviour vary's upon mode) |
| 12:59 | <gsnedders> | *varies |
| 12:59 | <zcorpan> | oh, they backported JScript quirks? |
| 13:01 | <jgraham> | Philip`: To be fair a raytracer is probably closer to the applications for which javascript performance is the main bottleneck |
| 13:01 | <gsnedders> | zcorpan: Seemingly so |
| 13:01 | <jgraham> | Which are often games and so on |
| 13:04 | <Philip`> | jgraham: I'm not particularly familiar with the details, but I don't think they're really that close - raytracing is mostly about searching spatial data structures, whereas normal games are more about iterating over arrays of data, or something like that |
| 13:05 | <jgraham> | Oh. Well I was thinking of arithmetic operation performance |
| 13:05 | <jgraham> | But maybe that isn't the real bottleneck |
| 13:05 | jgraham | thinks that http://benfirshman.com/projects/jsnes/ is a more fun benchmark |
| 13:06 | <gsnedders> | jgraham: It's not the arithmetic that's the bottleneck, it's what you have around the arithmetic (type checks, etc.) where perf is won/lost, which depends upon data structures you're doing it on far more. |
| 13:06 | <Philip`> | Multiplying numbers is usually trivial compared to reading them from memory, even when you're writing in C and reading them from memory doesn't involve potential dynamic property lookups |
| 13:10 | <jgraham> | gsnedders: Well clearly the datastructure matters. I would nevertheless be surprised if optimising a raytracer didn't help more with a typical game than optimising a javascript parser |
| 13:11 | <Philip`> | I'd expect the same, since presumably the parser is all string operations and games rarely use strings |
| 13:11 | <gsnedders> | Also, it's jslint running on jslint. Because testing yourself is what all code does! |
| 13:12 | <Philip`> | but I'd expect it to help much less than directly optimising the game, since the bottlenecks are likely in very different places |
| 13:12 | <jgraham> | Fair enough |
| 13:12 | <Philip`> | Not that my expectations actually mean anything, of course |
| 13:14 | Philip` | has only cared about performance in about one JS thing he wrote, and that seemed to be entirely limited by canvas image-drawing performance which he could do nothing about |
| 13:14 | <gsnedders> | Philip`: That's very much been what I've seen, FWIW |
| 13:15 | <Philip`> | I expect WebGL would typically change things around - GPUs are stupidly fast, so the problem is getting data from JS to the GPU |
| 13:16 | <gsnedders> | (Not that there haven't been things where JS engines could optimize better and make such modifications unneeded) |
| 13:16 | <gsnedders> | (e.g., gaussian-blur in Kraken) |
| 13:18 | <jgraham> | I think that's very unfair. There are plenty of games that awful on older javascript engines but quite playable on new ones. I am at least reasonably sure that it is not all down to canvas optimisations |
| 13:19 | <jgraham> | Unless it happened that all the browsers with highly optimised javascript implementations also had highly optimised canvas |
| 13:19 | <jgraham> | Which would make it hard to tell |
| 13:20 | <gsnedders> | jgraham: Well, there's the fact that ImageData nowadays is mostly implemented at a JS-engine level. |
| 13:21 | <Philip`> | jgraham: Yeah, my one was not representative of all games, since it pretty only did graphics and trivial collision-detection and didn't have any actual gameplay |
| 13:21 | <jgraham> | Yes. But that is not the only thing |
| 13:21 | <Philip`> | s/pretty/pretty much/ |
| 13:23 | <jgraham> | (alternative evidence for extreme case: try disabling JIT for some games and see what happens) |
| 13:25 | <gsnedders> | (JS is fun, though, because scripts tend to have such short execution times you can scarcely afford to do much optimization) |
| 13:28 | Philip` | remembers that he has another game with lots of JS code that is sometimes quite slow, so he should probably try porting it to run in a browser |
| 13:35 | Philip` | wonders if there's some trick to disabling JIT in Opera, like whether you have to reload the page or open a new tab or restart the browser |
| 13:38 | <gsnedders> | Philip`: It should pretty much insantly stop running JIT'd code |
| 13:41 | <Philip`> | I tried running some random tests like http://jsperf.com/caching-array-length/7 and don't see any significant differences when toggling the EcmaScriptJIT setting :-( |
| 13:41 | <Philip`> | (with 11.10 on 64-bit Linux) |
| 13:42 | Philip` | wonders if Opera doesn't bother JITting on 64-bit yet |
| 13:42 | <Philip`> | (Hmm, sounds like it ought to work) |
| 13:43 | <Philip`> | Also it could be that jsperf.com is useless |
| 13:43 | Philip` | knows nothing about this |
| 13:44 | <gsnedders> | Philip`: Hmm, seems like reloading is needed |
| 13:44 | gsnedders | thought it affected stuff insantly, not just when creating a new document |
| 13:45 | <gsnedders> | (shows how much I time I spend debugging stuff like that :P) |
| 13:45 | <Philip`> | Oh, I think I'm being stupid (unsurprisingly) |
| 13:45 | <Philip`> | I didn't realise there was a "save" button on opera:config and assumed it applied immediately |
| 13:46 | <gsnedders> | Philip`: You still need to reload the page |
| 13:47 | <Philip`> | Yeah |
| 13:47 | <Philip`> | Seems to be the case |
| 13:47 | <Philip`> | http://canvex.lazyilluminati.com/83/play.xhtml with JIT probably enabled: up to about 96fps; with JIT probably disabled: up to about 92fps |
| 13:49 | Philip` | wouldn't be surprised if the bottleneck now was the setInterval |
| 13:49 | <jgraham> | http://benfirshman.com/projects/jsnes/ 59ish FPS with JIT 10ish without |
| 13:52 | Philip` | expects emulators are entirely different to any non-emulated games, though it's nice for emulators to be fast for their own sake |
| 13:52 | <Philip`> | Finding representative applications is hard :-( |
| 13:54 | <jgraham> | That is true |
| 17:38 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=651888 |
| 17:38 | <MikeSmith> | Rik`: ↑ |
| 17:39 | <Rik`> | MikeSmith: maybe submit this idea to the devtools team |
| 17:39 | <MikeSmith> | ok |
| 17:39 | <MikeSmith> | how do I do that? |
| 17:40 | <Rik`> | well, I don't know the component :) |
| 17:40 | <TabAtkins> | Oh man, WebP finally has alpha, largely because Firefox complained that they wouldn't implement it without that. ^_^ |
| 17:40 | <Rik`> | product: Firefox component: developer tools |
| 17:41 | <MikeSmith> | Rik`: OK, I will also post it on #devtools |
| 17:41 | <MikeSmith> | or Moz irc |
| 17:43 | <MikeSmith> | Rik`: hmm, bugzilla UI does not seem to be offering me a "developer tools" component |
| 17:43 | <Rik`> | MikeSmith: Change product to Firefox and then submit the bug |
| 17:43 | <Rik`> | you'll see the Firefox components later |
| 17:43 | <Rik`> | (which is ugly) |
| 17:44 | <MikeSmith> | thanks |
| 17:44 | <MikeSmith> | done |
| 17:55 | <Rik`> | MikeSmith: again, bz answers in less than 30 minutes :) |
| 17:58 | <MikeSmith> | Rik`: heh :) |
| 17:59 | <MikeSmith> | I guess I knew about that shortcut |
| 17:59 | <MikeSmith> | but I thought I'd found that it doesn't always seem to work as expected |
| 17:59 | <MikeSmith> | but I could be wrong |
| 18:17 | <MikeSmith> | um |
| 18:17 | <MikeSmith> | can somebody please tell me how do I submit a Chrome enhancement request? |
| 18:18 | <MikeSmith> | because I seem to not be able to figure it out on my own |
| 18:20 | <espadrine> | Isn't this the same way as creating a bug request? |
| 18:20 | <espadrine> | http://code.google.com/p/chromium/issues/list or something? |
| 18:20 | <MikeSmith> | the Template select control at http://code.google.com/p/chromium/issues/entry does not provide anything appropriate for enhancements |
| 18:26 | <AryehGregor> | MikeSmith, I'm pretty sure "Defect report from user" is correct for enhancement requests. |
| 18:35 | <jgraham> | AryehGregor: You wanted assert_not_equals, right? |
| 18:35 | <AryehGregor> | jgraham, yeah. |
| 18:38 | <jgraham> | I added it |
| 18:38 | <jgraham> | (I meant to write that the first time rather than leave a dangling question) |
| 18:38 | <jgraham> | (but forgot) |
| 18:42 | <AryehGregor> | Thanks. |
| 18:49 | <AryehGregor> | jgraham, thanks. |
| 18:52 | <AryehGregor> | This is so typical of IEBlog: IE9 is clearly better at resisting web page hangs than two of the three competing browsers, and they could have written a totally fair post that made IE look great, but they had to write one that was half FUD instead. |
| 18:52 | <AryehGregor> | (this is actually one of my major gripes with Firefox, although I'm kind of atypical in the number of sites I visit with long-running scripts . . .) |
| 18:53 | <AryehGregor> | (by which I mean that most of the time I use Firefox I'm visiting a page with long-running script) |
| 18:53 | <jgraham> | Hmm, what does IE do? |
| 18:53 | <AryehGregor> | IE is tab-per-process, so in IE9 it has no problem tolerating any kind of per-tab hang. |
| 18:54 | <jgraham> | Oh, you mean like that |
| 18:54 | <AryehGregor> | So tabs can't hang the main UI, no matter what they do (in theory). |
| 18:54 | <jgraham> | OK |
| 18:54 | <AryehGregor> | As opposed to Firefox, which completely freezes while script is running in any tab. |
| 18:54 | <AryehGregor> | Apparently Opera doesn't freeze on long-running script, but they say it can freeze on other types of tab hangs. Not sure what that actually means. |
| 18:54 | <AryehGregor> | If anything. |
| 18:55 | <jgraham> | Well it means that we don't freeze on long running scripts |
| 18:55 | <jgraham> | But if you manage to, say, hang the parser it can freeze |
| 18:55 | <AryehGregor> | But that would only be due to a weird bug of some kind, right? |
| 18:55 | <AryehGregor> | Not something that's likely to be deliberately trigger-able. |
| 18:55 | <AryehGregor> | As opposed to while (true);. |
| 18:57 | <jgraham> | Well it is possible to make badness happen in the HTML5 algorithm I think |
| 18:57 | <jgraham> | Even with the limits |
| 19:07 | <espadrine> | As a matter of fact, Opera does hang quite a lot with huge pages with lots of nodes... |
| 19:15 | <MikeSmith> | AryehGregor: ok (about enhancement filing) |
| 19:18 | <othermaciej> | I'm guessing you can hang the engine in any browser if you force style resolution of many complex selectors in a giant document |
| 20:35 | <AryehGregor> | Can anyone explain to me why this is valid? http://validator.nu/?doc=data%3Atext%2Fhtml%2C%3C%21doctype+html%3E%3Ctitle%3E%3C%2Ftitle%3E%3Cimg+src%3Dx%3E&showsource=yes |
| 20:36 | <AryehGregor> | The img has no alt, and I can't see any applicable exception. |
| 20:38 | <Hixie> | looks like a bug |
| 20:39 | <jgraham> | I am suspicious that hsivonen has wanted to avoid messing about with the <img alt> stuff since it is clearly a huge rathole |
| 20:40 | <othermaciej> | AryehGregor: I think the validator implements the older rule of never reporting missing alt as an error |
| 20:40 | <AryehGregor> | Oh. |
| 20:40 | <othermaciej> | (it has the "image report" feature to give purely advisory guidance) |
| 20:40 | <AryehGregor> | I didn't know there was such a rule. |
| 20:40 | <othermaciej> | I believe that is 2 years obsolete now |
| 20:40 | <othermaciej> | at least |
| 21:15 | <AryehGregor> | So apparently my cell phone number is now available to all W3C members. |
| 21:15 | <AryehGregor> | Would be nice if the profile editing page made that just a bit clearer. |
| 21:15 | <TabAtkins> | I'm *this* close to being able to read Chinese and Japanese numbers, without consciously trying to learn this. |
| 21:16 | <TabAtkins> | I can already kinda read Tamil, because it was an interesting system that I spent a lot of time on. |
| 21:16 | <AryehGregor> | I can more or less read Japanese numbers. |
| 21:16 | <TabAtkins> | Also: it's pretty. |
| 21:17 | <wilhelm> | They mostly use Arabic numerals, though. :P |
| 21:19 | <AryehGregor> | Doesn't everyone? |
| 21:19 | <AryehGregor> | Israelis mostly use Arabic numerals, and they're even backwards. |
| 21:19 | <TabAtkins> | Cultural homogenization ftw |
| 21:20 | <AryehGregor> | Well, to be fair, it's a better system. |
| 21:20 | <AryehGregor> | You know, positional notation. |
| 21:20 | <TabAtkins> | That's why it's a win. |
| 21:21 | <AryehGregor> | Practically every other system can handle only fairly small numbers, totally useless for things like serial numbers. |
| 21:21 | <TabAtkins> | Yup. |
| 21:21 | <TabAtkins> | Generally 6 digits or less. |
| 21:21 | <AryehGregor> | There's like one language that MediaWiki supports (and it supports a ridiculous number of languages) that wants a different default <ol> list-style-type, IIRC. |
| 21:22 | <TabAtkins> | Which is? |
| 21:22 | <AryehGregor> | http://www.mediawiki.org/wiki/Localisation_statistics |
| 21:22 | <AryehGregor> | Maybe Persian? |
| 21:22 | <AryehGregor> | Sort that table in descending order by percentage translated. |
| 21:23 | <AryehGregor> | 11 languages with >99% translation, 37 with >95%. Wikis are awesome for translation. |
| 21:23 | <TabAtkins> | Yeah. |