| 00:47 | <zewt> | aho: by the way re: multiple range requests and reading multiple files out of a zip in one request, http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#page-11 |
| 00:47 | <aho> | heh |
| 00:47 | <zewt> | (we were confused before since we were looking at Content-Range, the response header, rather than the request header) |
| 00:50 | <aho> | gonna stick with gzipped (simple index + concatinated data) for now though... well, for my games, that is |
| 00:51 | <aho> | do you happen to know how to make xhr get cachable with opera? |
| 00:51 | <zewt> | don't know any workaround for that |
| 00:51 | <aho> | far future expires headers do nothing |
| 00:51 | <aho> | well... i could just stick all of that into local storage, but that looks kinda silly |
| 00:52 | <zewt> | you shouldn't have to reimplement http caching with web storage, heh |
| 00:52 | <aho> | also with a few games on one site that 5mb limit will be broken easily |
| 00:53 | <aho> | i probably should just ignore it for now |
| 00:53 | <zewt> | i think some mobile versions of google sites, like images.google, cache javascript in localStorage |
| 00:53 | <zewt> | pretty... gross, heh |
| 00:53 | <aho> | it works in any other browser and opera's market share is kinda small |
| 00:53 | <aho> | yea they pump js, css, and whatever into local storage in order to bypass awkward limitations of mobile browsers |
| 00:54 | <aho> | eg the iphone won't cache anything >25kb |
| 00:54 | <aho> | (or >15kb... depends on the version of the os) |
| 00:54 | <zewt> | that's another strangeness--if you're on a cell connection caching is even more important than usual, so it's strange that they don't cache as aggressively as available storage allows |
| 00:55 | <aho> | well, i can imagine why they did that |
| 00:55 | <zewt> | on early generation phones which had more limited storage, okay |
| 00:55 | <aho> | latency is very high... so they rather try to cache as many of those tiny files as possible |
| 00:55 | <zewt> | i don't know how much caching androidbrowser does, either |
| 00:55 | <aho> | personally, i think they should have differenciated between images and js though |
| 00:58 | <aho> | ah found it on reddit: http://www.reddit.com/r/javascript/comments/guj5m/the_mobile_version_of_bing_uses_localstorage_to |
| 00:59 | <aho> | also this thing: http://www.phpied.com/iphone-caching/ |
| 00:59 | <aho> | mobile browsers are disgusting :) |
| 01:00 | <zewt> | it's pretty fundamentally nonsensical to stop caching based on size--it means that optimizing loads by combining scripts into one file can lead to it not being cached |
| 01:02 | <aho> | yea |
| 01:02 | <aho> | or sprites... or merged css files |
| 01:02 | <aho> | (spritesheets) :> |
| 01:03 | <aho> | speaking of optimizations, i'm really looking forward to webp with alpha |
| 01:03 | <aho> | finally we will have some kind of lossy rgba image format on the web |
| 01:03 | <zewt> | i'm pretty badly unimpressed with webp |
| 01:03 | <aho> | (i still wish mozilla hadn't killed jng back then...) |
| 01:04 | <aho> | http://my.opera.com/chooseopera/blog/on-a-horse-opera-turbo-to-the-rescue |
| 01:04 | <aho> | it's somewhat smaller at usual quality and quit a lot smaller at somewhat acceptable quality |
| 01:04 | <aho> | well, the key point for me is lossy+alpha |
| 01:04 | <zewt> | it's aggrevating that with google in a position to push a newer image format, they're pushing a half-baked, narrow-focus one that isn't actually a general replacement for jpeg |
| 01:05 | <aho> | that's the only raison d'ĂȘtre it needs |
| 01:05 | <aho> | afaict it's at least as good as jpg |
| 01:06 | <zewt> | i remember off-hand that it has smaller resolution limitations; recall there being some other limitations but don't recall them off-hand |
| 01:07 | <aho> | 16383x16383 |
| 01:08 | <aho> | big enough for the web |
| 01:08 | <aho> | jpg is probably 64k x 64k |
| 01:08 | <aho> | (like png) |
| 01:08 | <zewt> | see, that's a narrow-minded focus, which is very different from the mindset of making a *general-purpose* image format |
| 01:08 | <zewt> | yep |
| 01:09 | <zewt> | i don't want to see an "image format for the web"; i want to see a general-purpose lossy image format, with one major use being the web |
| 01:09 | <aho> | lots of png loaders break apart at 32k though :> |
| 01:10 | <aho> | 16k is enough for most things though |
| 01:10 | <aho> | web, games, photos... |
| 01:10 | <zewt> | but it's smaller than jpeg, which means there are uses which jpeg handles and webp does not, which means jpeg isn't completely obsoleted |
| 01:11 | <aho> | print (up to A4, i guess) |
| 01:11 | <aho> | true |
| 01:11 | <zewt> | i don't want to see "use the new format, unless you need to do this list of uncommon but valid things:" |
| 01:12 | <aho> | well, you won't need to tell that anyone. webp simply won't be available as option if the dimensions are too big |
| 01:13 | <aho> | or if the bitdepth is too high |
| 01:13 | <zewt> | and now they have to worry about the differences between the formats, instead of forgetting about the obsolete format; and they'll have to do this effectively forever |
| 01:14 | <zewt> | which is the main problem--if webp gains traction we'll probably not see a new generation of lossy still image compression for 20+ years |
| 01:14 | <aho> | well, we can use jp2 in about 10 years :> |
| 01:14 | <aho> | (jpeg2000) |
| 01:16 | <aho> | either way, this is my primary concern: http://kaioa.com/b/1011/jng_decision_matrix.svgz |
| 01:16 | <aho> | thing is, people do it anyways and the pages get *amazingly* fat |
| 01:17 | <zewt> | i wonder how it handles alpha-channel artifacting; if artifacts cause pixels to become partially opaque where they were originally fully transparent, it effectively displays undefined pixels in the color channels |
| 01:18 | <aho> | yes, but that doesn't really matter |
| 01:19 | <aho> | there are wrong colors, but the opacity will be very low |
| 01:19 | <zewt> | it matters if you jack the compression level up high enough to create nontrivial artifacts |
| 01:19 | <aho> | http://kaioa.com/b/1102/svgjng/index.html <- take a look (with opera) |
| 01:19 | <zewt> | which is less of a problem with better compression, but it's always possible |
| 01:20 | <zewt> | i guess it'd probably not look any more wrong than the other rgb compression artifacts that would also happen |
| 01:21 | <aho> | webp will most likely support two modes for alpha: lossy and lossless (similar to jng) |
| 01:22 | <aho> | the quality of the alpha channel can be changed independently |
| 01:22 | <aho> | so, you do have some control how broken the result will look |
| 01:26 | <zewt> | also, i assume webp doesn't address animations and sprites; animations aren't so important but they're logically identical to sprites, which are |
| 01:27 | <aho> | foo.webp#bar foo.webp#baz etc would be cool |
| 01:28 | <aho> | well... probably the wrong place ;) |
| 01:28 | <zewt> | well, less concerned about how it's exposed at the higher level as there being support for it within the file format--if it's supported by the format then web APIs using it will follow, if it's finalized and deployed without it, well... |
| 01:30 | <aho> | feel free to discuss that with the people over at #vp8 |
| 01:30 | <aho> | skal is the dude who's working on alpha, by the way |
| 01:31 | <aho> | i for one don't really know if having multiple "pages" makes much sense with that format |
| 01:38 | <aho> | on a somewhat related note, i wonder if i should write some canvas based jpg+jpg or jpg+png splicing thing, which uses localStorage to store the result |
| 01:38 | <aho> | would be fun, i guess |
| 01:39 | <aho> | but it also got some kind of passive-aggressive martyr taste to it :> |
| 02:23 | <Hixie> | MikeSmith: let me know when you need me to regen the spec for publication |
| 02:25 | <MikeSmith> | hai |
| 02:27 | <Hixie> | i'll try to avoid having any big patches outstanding this time so i can actually do it unlike last time :-) |
| 02:29 | <MikeSmith> | heh |
| 02:30 | <MikeSmith> | so everything on the W3C cvs side is ready |
| 02:30 | <MikeSmith> | the boilerplate |
| 02:31 | <MikeSmith> | and I have not made any changes since last time, so there should be no cvs conflicts |
| 02:31 | <MikeSmith> | I think |
| 02:47 | <MikeSmith> | is there are use case for a nested <figure> ? |
| 02:52 | <aho> | http://i.imgur.com/DTJtA.jpg |
| 02:52 | <aho> | :I |
| 02:52 | <aho> | other than that... no |
| 02:56 | <karlcow> | MikeSmith: there is http://1.bp.blogspot.com/_zuKg9DRLTjI/TE81sUrCcvI/AAAAAAAABBM/sM52ZHhhXFY/s1600/mise_en_abyme.jpg ;) |
| 02:56 | <MikeSmith> | heh |
| 05:08 | <karlcow> | http://arstechnica.com/web/news/2011/04/google-builds-webm-patent-pool-of-its-own-to-fight-back-against-mpeg-la.ars |
| 05:54 | <Hixie> | MikeSmith: did you commit the new headers? |
| 05:55 | <Hixie> | MikeSmith: i did cvs up but it didn't do anything |
| 05:56 | <ben_h> | hey dudes |
| 06:00 | <MikeSmith> | Hixie: I didn't make any changes to the headers, because I thought the plan was just to regen a new ED |
| 06:00 | <Hixie> | oh ok |
| 06:00 | <MikeSmith> | should I be flipping it to WD? |
| 06:00 | <Hixie> | sorry i thought they wanted a WD |
| 06:00 | <Hixie> | i dunno |
| 06:00 | <MikeSmith> | hmm |
| 06:00 | <MikeSmith> | yeah, I'm not sure either |
| 06:00 | <othermaciej> | no |
| 06:00 | <MikeSmith> | but I don't think they want to do a new WD |
| 06:00 | <Hixie> | ok |
| 06:00 | <othermaciej> | the request was just to update the ED |
| 06:00 | <Hixie> | well then nevermind! |
| 06:00 | <MikeSmith> | heh |
| 06:00 | <othermaciej> | since it was out of sync |
| 06:01 | <Hixie> | oh right, it's still out of sync |
| 06:01 | <MikeSmith> | I'm good at neverminding |
| 06:01 | <Hixie> | let me try regenning |
| 06:01 | <MikeSmith> | Hixie: I hope the changes I committed for the April 05 WD publication didn't bork up the regen process |
| 06:02 | <Hixie> | no, it's some xml problem with pms |
| 06:02 | <MikeSmith> | but if it did, I would imagine you'd be seeing conflict messages from csv |
| 06:02 | <Hixie> | nothing to do with the cvs stuff |
| 06:02 | <MikeSmith> | *cvs |
| 06:02 | <Hixie> | yeah |
| 06:02 | <MikeSmith> | ok |
| 06:03 | <MikeSmith> | ben_h: hey Lads |
| 06:03 | <Hixie> | ooh, it worked |
| 06:03 | <Hixie> | cool |
| 06:03 | <ben_h> | :) sup mike? |
| 06:04 | <MikeSmith> | ben_h: too much excitement, I think I'm going to change careers and become a gardener |
| 06:05 | <ben_h> | ha! |
| 06:05 | <ben_h> | who's been causing all the ruckus? |
| 06:06 | <MikeSmith> | the Web platform |
| 06:06 | <MikeSmith> | if the Web platform could just be sensible and easier to work with, we'd all be much happier |
| 06:07 | <MikeSmith> | ben_h: you guys making the pilgrimage to Japan again this summer? |
| 06:09 | <ben_h> | most definitely |
| 06:09 | <MikeSmith> | sweet |
| 06:09 | <ben_h> | i mean, nothing's organised or booked - but i'm going |
| 06:10 | <ben_h> | i get this nostalgic feeling when i think of japan |
| 06:10 | <MikeSmith> | me too |
| 06:10 | <ben_h> | something about it. what a place |
| 06:10 | <MikeSmith> | and I live here! |
| 06:10 | <ben_h> | hahaha |
| 06:10 | <ben_h> | even though i've only spent a month there :) |
| 06:10 | <MikeSmith> | you all should stay in my neighborhood again |
| 06:10 | <ben_h> | mmm, would love to |
| 06:11 | <ben_h> | might get an apartment for during the conference, and then stay in a couple of ryokans |
| 06:11 | <ben_h> | no hotels this time :) |
| 06:11 | <MikeSmith> | yeah, hotels are boring |
| 06:11 | <ben_h> | mmm |
| 06:11 | <MikeSmith> | speaking of summer, Robert Frost once wrote a poem about the Web platform. he called it "The Oven Bird" |
| 06:12 | <MikeSmith> | The bird would cease and be as other birds / But that he knows in singing not to sing. / The question that he frames in all but word / Is what to make of a diminished thing. |
| 06:13 | <TabAtkins> | Dammit, now I'm bleeding. |
| 06:14 | <MikeSmith> | TabAtkins: did you fall upon the thorns of life again? |
| 06:14 | <TabAtkins> | Fell off my bike on the way back to the office. |
| 06:14 | <TabAtkins> | It'll teach me not to talk to rollerbladers while riding on the sidewalk. |
| 06:15 | <MikeSmith> | heh |
| 06:15 | <MikeSmith> | you should claim it as a genuine crash, instead of a falling off |
| 06:16 | <MikeSmith> | crashing is cool, like Evel Kneivel |
| 06:16 | <TabAtkins> | True. |
| 06:16 | <MikeSmith> | he even looks like you! |
| 06:16 | <MikeSmith> | http://upload.wikimedia.org/wikipedia/commons/5/5e/At_Home_With_Evel_Knievel.jpg |
| 06:16 | <TabAtkins> | ...yes. He looks exactly like me. |
| 06:16 | <MikeSmith> | or maybe it's just the similar clothing |
| 06:17 | <MikeSmith> | Thomas Hardy also once wrote about poem about the Web Platform |
| 06:18 | <MikeSmith> | or more precisely I guess about that the work related to getting it standardized |
| 06:18 | <MikeSmith> | he called his poem "The Convergence of the Twain" |
| 06:18 | <MikeSmith> | and he used the term "vaingloriousness" in it |
| 06:18 | <MikeSmith> | which is one of the greatest words in the language |
| 06:19 | <MikeSmith> | "The intimate welding of their later history" |
| 06:19 | <TabAtkins> | I remember that poem. And that word. |
| 06:19 | <MikeSmith> | yeah, it is seriously great |
| 06:19 | <MikeSmith> | "consummation comes, and jars two hemispheres" |
| 06:20 | <MikeSmith> | the even better thing about that word is that in the poem, the people who use it are fishes |
| 06:20 | <MikeSmith> | so even fishes know the word "vaingloriousness" |
| 06:22 | <MikeSmith> | the actual original line that Hardy wrote for the fishes was, "WTF this vaingloriousness down here?" |
| 06:22 | <MikeSmith> | but his editor made him change it |
| 06:22 | <MikeSmith> | it's not clear why |
| 06:22 | <TabAtkins> | Fucking editors. |
| 06:22 | <MikeSmith> | maybe he thought that fishes don't know about "WTF" |
| 06:23 | <MikeSmith> | TabAtkins: amen |
| 06:23 | <MikeSmith> | edtors, as a class, are absolutely nothing but trouble and a massive PITA |
| 06:23 | <paul_irish> | TabAtkins: fine work tonight |
| 06:23 | <TabAtkins> | Can't live with 'em. |
| 06:23 | <TabAtkins> | paul_irish: Thanks! |
| 06:26 | <MikeSmith> | btw, I finished implementing http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-conformance-checkers in my validator.nu workspace today |
| 06:26 | <MikeSmith> | and pushed it to http://www.w3.org/html/check for testing |
| 06:27 | <MikeSmith> | so if anybody has time and interest in helping to test it, please test it there |
| 06:27 | <MikeSmith> | it's pretty straightforward except for the stuff related to figure and figcaption |
| 06:28 | <MikeSmith> | which I think I have right but not sure |
| 06:57 | <MikeSmith> | othermaciej: Hixie commit to http://dev.w3.org/html5/spec/ done |
| 09:52 | <zcorpan> | MikeSmith: is it publication time? |
| 09:53 | <MikeSmith> | zcorpan: no, just getting W3C copy synced up |
| 09:53 | <zcorpan> | oh |
| 09:54 | <zcorpan> | lemme know when i should get html-differences up to speed; i don't always read public-html :) |
| 09:58 | <MikeSmith> | ok |
| 10:01 | <othermaciej> | zcorpan: I don't think there will be another publication before LCWD, unless that gets dragged out |
| 10:01 | <zcorpan> | othermaciej: ok |
| 10:02 | <othermaciej> | which reminds me that I should raise the topic of CR exit criteria |
| 10:02 | <othermaciej> | maybe it would be good to write those before 1st LC |
| 10:10 | jgraham | wonders if "CR exit criteria" are "criteria for reaching CR" or "criteria for reaching PR" |
| 10:10 | <othermaciej> | traditionally CR exit criteria are the criteria to exit CR |
| 10:10 | <othermaciej> | the spec is supposed to fulfill them to exit CR |
| 10:11 | <othermaciej> | usually it's something about test suite, implementations, yada yada |
| 10:11 | <jgraham> | PR entrance criteria |
| 10:11 | <othermaciej> | however I believe the spec has to contain (as opposed to fulfill) them before entering CR |
| 10:11 | <jgraham> | The process document doesn't really talk about exit criteria afaict |
| 10:19 | <othermaciej> | it seems we do need to prepare a list of "at risk" features |
| 10:20 | <othermaciej> | and a "a report of present and expected implementations" |
| 10:20 | <othermaciej> | Also PR entrance criteria include: |
| 10:21 | <othermaciej> | 2. Shown that each feature of the technical report has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director may accept to Call for Review of a Proposed Recommendation even without adequate implementation experience; |
| 10:21 | <othermaciej> | 3. Satisfied any other announced entrance criteria (e.g., any included in the request to advance to Candidate Recommendation, or announced at Last Call if the Working Group does not intend to issue a Call for Implementations). |
| 10:21 | <othermaciej> | #3 is presumably what is often called CR exit criteria but which in the Process document are PR entrance criteria |
| 10:23 | <othermaciej> | CSS specs seem to say "Candidate Recommendation Exit Criteria" but then "For this specification to enter Proposed Recommendation, the following conditions must be met:" |
| 10:23 | <othermaciej> | so it does seem to be a Process thing, though any requirement beyond the general one about interoperable implementations of each feature seems to be optional |
| 10:23 | <jgraham> | That one is strictly optional too |
| 10:24 | <jgraham> | Since it starts "preferably" |
| 10:24 | <jgraham> | It seems like a good idea however |
| 10:25 | <jgraham> | Or, rather, the other option there seems irrelevent |
| 10:27 | <jgraham> | So CSS required two complete interoperable implementaions, not two per feature. |
| 10:27 | <othermaciej> | hmm, I was going to site the Selectors API CR exit criteria |
| 10:27 | <othermaciej> | which I believe are like the CSS ones |
| 10:27 | <othermaciej> | but they are not in the spec |
| 10:28 | <othermaciej> | I like "two complete interoperable implementations" personally, even though for HTML5 that is a tall order |
| 10:28 | <othermaciej> | but it might be that the test suite is the hard part |
| 10:30 | <zcorpan> | have we got any tests from selling t-shirts yet? |
| 10:31 | <jgraham> | I like it in principle, but I think it could create a lot of negative pressure at the end to cut features or make worse tests |
| 10:31 | <jgraham> | At the moment we don't even knoww what a complete implementation would look like |
| 10:32 | <othermaciej> | I think every feature that doesn't yet have at least one reasonable implementation (maybe any that doesn't have two) should be marked "at risk" |
| 10:32 | <othermaciej> | then future generations can make the tradeoff between finalizing HTML5 faster vs having more things in HTML5 rather than deferred to 5.1/6/whatever |
| 10:32 | <jgraham> | That seems fair |
| 10:33 | <jgraham> | But I think there will be a lot of perfectly reasonable implementations of things that don't quite pass the testsuite |
| 10:33 | <jgraham> | If the testsuite is any good |
| 10:33 | <jgraham> | Which it is mostly not so far |
| 10:33 | <othermaciej> | this is why I think the test suite may be the hard part |
| 10:34 | <jgraham> | I fully agree that the testsuite will be the hard part |
| 10:34 | <othermaciej> | I don't even know how to reasonably express test suite adequacy in the exit criteria |
| 10:34 | <othermaciej> | I wonder how thorough something like the JCK is compared to the standard we might want for the HTML5 test suite |
| 10:34 | <jgraham> | Well ideally I would like to have some metric for spec coverage |
| 10:34 | <jgraham> | Like percentage of assertions in the spec |
| 10:35 | <jgraham> | that have tests |
| 10:35 | <jgraham> | ignoring cross dependencies |
| 10:35 | <jgraham> | Which would be something like a normal code coverage metric |
| 10:35 | <othermaciej> | I would guess you'd want 100% of testable assertions to have tests |
| 10:35 | <jgraham> | Yes |
| 10:35 | <othermaciej> | but then you have to sort out which MUSTs are relevant to the conformance class being tested, and which are in fact testable |
| 10:36 | <jgraham> | The problem is that making such a metric turns out to be highly non-trivial on its own |
| 10:36 | <jgraham> | Philip` did it for the 2D API spec, but it is non trivial to scale |
| 10:37 | <jgraham> | http://philip.html5.org/tests/canvas/suite/tests/spec.html |
| 10:39 | <Philip`> | Will we need to have two complete interoperable implementations of HTML5 validators too? |
| 10:40 | <othermaciej> | well that is another interesting question - which conformance classes are relevant? |
| 10:41 | <jgraham> | Do we need two interoperable implementations of HTML authors? |
| 10:41 | <jgraham> | Because I have never seen two authors agree on correct usage :) |
| 10:42 | <othermaciej> | "Web browsers and other interactive user agents" are an almost-superset of the requirements for many of the other conformance classes |
| 10:42 | <othermaciej> | conformance checkers are the only other class that is even plausibly testable |
| 10:46 | <jgraham> | Are there *any* existing tests for conformance checkers? |
| 10:47 | <Philip`> | I'm sure I've seen some conformance tests for validator.nu |
| 10:49 | <Philip`> | It seems hard to test the spec comprehensively when it doesn't distinguish between document conformance requirements that are mechanically verifiable and those that aren't |
| 10:53 | <jgraham> | Is that something that needs interpretation, or just something that can be mechanically deduced from the conformance requirment? |
| 10:55 | <othermaciej> | I don't think it can be deduced by machine which document conformance requirements are machine-testable |
| 10:57 | <MikeSmith> | there are some vaiidator/document-conformance test documents here: |
| 10:57 | <MikeSmith> | https://bitbucket.org/validator/syntax/src/tip/relaxng/tests/ |
| 10:57 | <MikeSmith> | and here: http://dev.w3.org/html5/tests/validation/full/ |
| 11:00 | <MikeSmith> | speaking of validator testing, I have what I hope is complete support for the current alternative-text checking criteria in the current spec |
| 11:00 | <MikeSmith> | at http://www.w3.org/html/check for testing |
| 11:00 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-conformance-checkers <- this section |
| 11:01 | <MikeSmith> | zcorpan: â (if you have any time to try it) |
| 11:01 | <MikeSmith> | hey david_carlisle |
| 11:03 | <david_carlisle> | MikeSmith: hi |
| 11:04 | <MikeSmith> | thanks for the help on the 〈 thing |
| 11:05 | <david_carlisle> | didn't help much, just dumped it in bugziila for you to sort out:-) |
| 11:06 | <MikeSmith> | I hope Hixie will sort it out upstream so that I don't have to hack around it |
| 11:06 | <hsivonen> | someone has missed a memo: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12563 |
| 11:06 | <MikeSmith> | Philip`: btw, I tried running the splitter with --html5lib-parser |
| 11:07 | <MikeSmith> | and I get: |
| 11:07 | <MikeSmith> | File "html5-tools/spec-splitter/spec-splitter.py", line 82, in <module> |
| 11:07 | <MikeSmith> | doctitle = doc.find('.//title').text |
| 11:07 | <MikeSmith> | AttributeError: 'NoneType' object has no attribute 'text' |
| 11:07 | <MikeSmith> | but I don't get that when I omit that switch |
| 11:08 | <david_carlisle> | MikeSmith: You know you should all have used xmlspec xml and tools to generate the specs, your lives would be so much happier, all this html and python will lead to tears |
| 11:08 | <MikeSmith> | heh |
| 11:08 | <MikeSmith> | no thanks |
| 11:16 | <AryehGregor> | "If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices." http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx |
| 11:17 | <AryehGregor> | $ wget -qO- http://www.webm-ccl.org/members/ | grep Microsoft; echo $? |
| 11:17 | <AryehGregor> | 1 |
| 11:17 | <AryehGregor> | Hmm. |
| 11:17 | <AryehGregor> | I guess "all other major providers of playback software and devices" is a tall order. |
| 11:17 | <MikeSmith> | hsivonen: the patch I sent you for review today is up to date with both the spec and the recent WG decision about conformance criteria for alternative text (I think) |
| 11:20 | <Philip`> | MikeSmith: Hmm, I'm sure --html5lib-parser worked at some point in the past |
| 11:20 | <Philip`> | but I don't know which point |
| 11:21 | <othermaciej> | I wonder how many of the companies on the list even have any video-related patents |
| 11:21 | <MikeSmith> | maybe still works, just not in my environment |
| 11:21 | <MikeSmith> | or something |
| 11:21 | <othermaciej> | since you don't get told what patents are in the pool, I guess it is hard to find out |
| 11:21 | <AryehGregor> | The way the pool is set up, it seems like the companies themselves might not know which of their patents are in the pool, right? |
| 11:22 | <AryehGregor> | MPEG LA needs you to list the exact patents because they don't want to give you royalties if you don't really have an applicable patent. |
| 11:22 | <hsivonen> | MikeSmith: ok. Looking now. |
| 11:22 | <AryehGregor> | "Persons joining the WebM Community Cross-License will not be required to identify Covered Patents. " |
| 11:23 | <othermaciej> | W3C also doesn't require you to list patents that you won't assert on a spec |
| 11:24 | <hsivonen> | MikeSmith: this is going to make schematron and SchematronEquiv diverge, right? |
| 11:27 | <hsivonen> | s/SchematronEquiv/Assertions/ |
| 11:29 | <MikeSmith> | hsivonen: I have not tried to write it up in schematron yet |
| 11:30 | <MikeSmith> | are there parts of it that aren't implementable in schematron? |
| 11:31 | <hsivonen> | MikeSmith: dunno yet |
| 11:31 | <MikeSmith> | OK |
| 11:32 | <MikeSmith> | anyway, I think there is at least one other case of something I added to the Assertions checker that I did not add to the schematron stuff, because it was not practical (or maybe not even possible) to implement it in schematron/xpath as far as I could see |
| 11:32 | <MikeSmith> | but I can't remember right now what that was |
| 11:40 | <hsivonen> | MikeSmith: I sent you email about the patch |
| 11:40 | <MikeSmith> | thanks |
| 13:54 | <wilhelm> | Hixie: So, should we go for blacklists or whitelists for register*Handler()? (c: |
| 15:29 | <AryehGregor> | Okay, back to work for me. |
| 15:49 | <AryehGregor> | . . . Google has disappeared from my search engine list in Firefox 5.0a2, and I can't see any way to get it back. |
| 15:52 | <AryehGregor> | Plus Firebug disabled itself. |
| 15:52 | AryehGregor | switches back to Firefox 4 |
| 15:59 | <jgraham> | Google seems to be in the search engine list for me (in 6) |
| 15:59 | <AryehGregor> | Firefox 6? |
| 16:00 | <AryehGregor> | I thought they were only up to 5, even in nightlies. |
| 16:00 | <jgraham> | Yeah |
| 16:00 | <jgraham> | No, 5 is Auora |
| 16:00 | <AryehGregor> | Or is Aurora 5, and nightly is 6? |
| 16:00 | <AryehGregor> | Oh. |
| 16:00 | <jgraham> | I had to futz to get firebug working |
| 16:00 | <jgraham> | fb .18 should work in 5 it seems |
| 16:01 | <jgraham> | *1.8 |
| 16:01 | <jgraham> | But you have to disable the compat check in 6 |
| 16:20 | <AryehGregor> | Weird. Why does surroundContents(docfrag) raise an INVALID_NODE_TYPE_ERR in all browsers? |
| 16:21 | <TabAtkins> | Useless answer: Because a docfrag is an invalid node type? |
| 16:21 | <AryehGregor> | Hmm, the insertNode() thing should fail somehow. |
| 16:22 | <AryehGregor> | When it calls insertBefore(). |
| 16:22 | <AryehGregor> | But that should be a HIERARCHY_REQUEST_ERR or something, not an INVALID_NODE_TYPE_ERR . . . |
| 16:22 | AryehGregor | will investigate further |
| 16:30 | <smaug____> | So http://mdv.googlecode.com/svn/trunk/docs/design_intro.html is effectively JS-fied XForms :) |
| 16:30 | <TabAtkins> | The "JSified" is the important part! |
| 16:31 | <smaug____> | not sure why |
| 16:32 | <TabAtkins> | Because it's what you actually want, given the common and appropriate paradigm of JS being your canonical source of data. |
| 16:32 | <AryehGregor> | Oh, DOM 2 Range says it should raise an INVALID_NODE_TYPE_ERR in that case . . . |
| 16:32 | <AryehGregor> | I have no idea why, but . . . |
| 16:33 | <hsivonen> | TabAtkins: huh? not RDF as the canonical source of data? |
| 16:33 | <TabAtkins> | hsivonen: ::shudder:: |
| 16:33 | <TabAtkins> | Anyway, I meant in the context of a running application. Your data storage can be RDF or SQL or whatever. |
| 16:34 | <TabAtkins> | The point is that the data is canonical in the JS, not the DOM, so the DOM is just a view of the data. |
| 16:50 | jgraham | wonders if the {{ }} syntax will cause problems with common server-side templating langauges |
| 16:53 | <AryehGregor> | Do common server-side templating languages often use {{}}? Other than wikitext . . . |
| 16:54 | <jgraham> | Dunno. Some use ${} which is slightly uncomfortably close |
| 17:00 | <Philip`> | Django uses {{...}} |
| 17:00 | <Philip`> | http://docs.djangoproject.com/en/dev/topics/templates/#variables |
| 17:19 | Philip` | thinks http://blogs.msdn.com/b/ie/archive/2011/04/27/ie9-compat-inspector.aspx looks like a nice idea since it gives useful error messages (suggesting upgrading specific JS libraries etc, instead of just moaning that there's an error), and also it doesn't suggest x-ua-compatible or attempt to disparage other browsers |
| 17:20 | <gsnedders> | Philip`: I wonder if they change whether they list depending on libraries are loaded |
| 17:23 | <jgraham> | Philip`: Yes, indeed. Foregoing marketing-driven mudslinging and instead providing helpful technical insight ftw |
| 17:24 | <Philip`> | gsnedders: They don't (except for one test that's conditional on window.jQuery, reporting a bug in old jQuery versions) |
| 17:25 | <Philip`> | I presume if you're maintaining a site then you probably already know what JS libraries it's using (or can easily find out) |
| 17:26 | <gsnedders> | Philip`: Hm, okay. I guess that's reasonable (libraries bound to different variables, etc.). |
| 17:26 | <Philip`> | and it seems to have a separate thing that tells you what libraries it detects anyway |
| 17:26 | <Philip`> | (but doesn't use that detection to alter any of the error messages) |
| 17:47 | <AryehGregor> | + if (y !== y) |
| 17:47 | <AryehGregor> | + { |
| 17:47 | <AryehGregor> | + //NaN case |
| 17:47 | <AryehGregor> | + return y !== y; |
| 17:47 | <AryehGregor> | + } |
| 17:47 | <AryehGregor> | jgraham, I guess you mean return x !== x there? |
| 17:47 | <AryehGregor> | I'll fix it. |
| 17:48 | <gsnedders> | x and y being expected and actual? |
| 17:48 | <AryehGregor> | Yes. |
| 17:49 | <AryehGregor> | Fix pushed. |
| 17:49 | <gsnedders> | Ergh, can we not have one letter variables? |
| 17:49 | <AryehGregor> | Well, it's actually a same_value(x, y) function. |
| 17:49 | <AryehGregor> | So the two values are interchangeable, strictly. |
| 17:50 | <AryehGregor> | It happens to be that it's primarily used for expected and actual, but it doesn't have to be. |
| 17:50 | <AryehGregor> | So x and y are fairly appropriate here. |
| 17:51 | <Philip`> | for (var iterator = 0; iterator < 10; ++iterator) alert('I sometimes like short variable names'); |
| 17:55 | <jgraham> | AryehGregor: Thanks |
| 17:56 | <jgraham> | gsnedders: As long as you don't use one letter variables in your programming-by-hand exams :p |
| 17:57 | <jgraham> | (unless it is in Fortran. Then you are required to use one letter variables by the law of unreadable scientific code) |
| 17:57 | <jgraham> | (you can use two letters when you run out of one letters) |
| 17:57 | <gsnedders> | jgraham: I did only in lambdas, and where the questions gave arguments one-letter names. |
| 17:58 | <gsnedders> | jgraham: Or do what GWT does and just vary case |
| 18:00 | <jgraham> | That still only gives you 52 ascii letters to play with |
| 18:00 | <jgraham> | Naming things pWz or similar is encouraged |
| 18:01 | <AryehGregor> | jgraham, you know that instanceof appears to always return false in WebKit, in some cases? |
| 18:01 | <AryehGregor> | Specifically, ones I keep hitting in my tests. |
| 18:01 | AryehGregor | investigates |
| 18:02 | <AryehGregor> | Things like e instanceof Object being false, where e is a DOMException. |
| 18:02 | <Philip`> | jgraham: 52 is loads - x86 only gives you about 8 'variables' you can use at once, and that works fine |
| 18:02 | <AryehGregor> | Six, if you don't want to mess with the stack. |
| 18:02 | <Philip`> | You just need a separate array to overflow your set of variables into |
| 18:02 | <jgraham> | Point |
| 18:03 | <jgraham> | AryehGregor: That sounds like a bug |
| 18:03 | <jgraham> | In WebKit |
| 18:03 | <AryehGregor> | jgraham, yeah, it does, doesn't it? |
| 18:03 | AryehGregor | doesn't really want to make a reduced test case from several thousand lines of code, but it would be nice to be able to work around this better . . . |
| 18:04 | <jgraham> | You might be able to work out what is going on it Web Inspector |
| 18:05 | <jgraham> | wilhelm: You should file the Gecko bug you found btw |
| 18:05 | <gsnedders> | AryehGregor: If only jgraham's framework had something like QuickCheck's reduce functionality |
| 18:05 | <AryehGregor> | What does that do? |
| 18:05 | <AryehGregor> | Hmm, yeah, let me try Web Inspector first. |
| 18:05 | <AryehGregor> | Although I think I tried it before and didn't get what was going on. |
| 18:05 | <gsnedders> | AryehGregor: It's reduces the Haskell down to a minimal TC it can programmatically find that fails |
| 18:06 | <jgraham> | gsnedders: Well you could use it with one of the tools for doing that to js |
| 18:06 | <jgraham> | I guess it likely won't be as elegant as QuickCheck |
| 18:07 | <AryehGregor> | Okay, so in the console I've got !(e instanceof Object) and typeof e == "object". |
| 18:07 | <AryehGregor> | Any ideas on what to look at from here? |
| 18:07 | <AryehGregor> | Oh, hmm. |
| 18:07 | <AryehGregor> | I think the exception was thrown in a different window. |
| 18:07 | <AryehGregor> | In an iframe, specifically. |
| 18:07 | <AryehGregor> | Maybe that's it? |
| 18:08 | <AryehGregor> | So the interface objects aren't equal on the different windows? |
| 18:08 | AryehGregor | tests |
| 18:08 | <jgraham> | Oh yes, that is a known issue |
| 18:08 | <AryehGregor> | Yeah, e instanceof actualIframe.contentWindow.Object is true. |
| 18:08 | <AryehGregor> | So any way to work around that? |
| 18:09 | <jgraham> | I⊠don't remember |
| 18:09 | <gsnedders> | ES doesn't interact well with multiple globals |
| 18:09 | <jgraham> | I thought I was going to provide a way to pass in a window object |
| 18:09 | <jgraham> | Did I? |
| 18:10 | Philip` | presumes the interfaces couldn't be equal else you could do "Object.foo = 1" in one iframe and read it back in another and get cross-origin communication |
| 18:10 | <jgraham> | That's not how instanceof is specced to work in WebIDL I think |
| 18:10 | <AryehGregor> | Evil. |
| 18:11 | <jgraham> | But... yeah |
| 18:13 | <AryehGregor> | Does WebIDL actually define instanceof? |
| 18:13 | AryehGregor | looks in ES5 |
| 18:13 | <Ms2ger> | I hope so! |
| 18:14 | <AryehGregor> | Ah, [[HasInstance]]. |
| 18:14 | <jgraham> | AryehGregor: [[HasInstance]] |
| 18:14 | <jgraham> | too slow :( |
| 18:14 | <AryehGregor> | "If V is a host object that implements the interface for which O is the interface prototype object, return true." |
| 18:14 | <AryehGregor> | But "If O and V refer to the same object, return true." |
| 18:15 | <AryehGregor> | It doesn't seem to have thought of this case. |
| 18:15 | <jgraham> | I think only heycam really understands what is going on ;) |
| 18:15 | <jgraham> | But yeah, he said it hadn't considered this case |
| 18:16 | <jgraham> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12295 |
| 18:18 | <jgraham> | Is it surprising the things that come upo really quickly when you start testing stuff that are otherwise quite obscure |
| 18:18 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/961 |
| 18:18 | <AryehGregor> | Only works in Firefox. |
| 18:18 | <AryehGregor> | I mean, logs "true" in Firefox, "false" in everyone else. |
| 18:19 | <AryehGregor> | I don't suppose objects are associated with a particular window that we can get, or anything like that? |
| 18:23 | <AryehGregor> | Okay, so for now we want to just remove all instanceof checks from testharness.js. |
| 18:23 | <AryehGregor> | Since the behavior isn't really defined. |
| 18:28 | <AryehGregor> | Done |
| 18:28 | <AryehGregor> | . |
| 18:37 | <AryehGregor> | jgraham, regarding r239, why did you remove the e.name === code_or_object check? The spec does require it. |
| 18:37 | <AryehGregor> | Just because it makes all the assertions fail in some browsers? |
| 18:42 | <wilhelm> | jgraham: Yes, will do. |
| 18:50 | <AryehGregor> | Hmm, every use of assert_throws in DOM Range tests is apparently wrong. |
| 18:50 | <AryehGregor> | At least, the ones that don't test DOMExceptions. |
| 18:50 | <AryehGregor> | Which is a minority. |
| 18:54 | <jgraham> | AryehGregor: Because of sekrit backchannel information from annevk |
| 18:54 | <jgraham> | (that the spec might change) |
| 18:54 | <AryehGregor> | jgraham, more specifically? |
| 18:54 | <AryehGregor> | Oh. |
| 18:54 | <AryehGregor> | To what? |
| 18:54 | <AryehGregor> | The current spec seems sane. |
| 18:55 | <jgraham> | Yeah, I like it |
| 18:55 | <AryehGregor> | Saner than what any browser does, anyway. |
| 18:55 | <AryehGregor> | Also, I just convinced some people in the Web Apps WG to copy it for their own exception types. |
| 18:55 | <jgraham> | I think it might be closer to what some browser does |
| 18:55 | <AryehGregor> | I think approximately one browser actually implements it correctly. |
| 18:55 | <AryehGregor> | WebKit, perhaps? |
| 18:55 | <jgraham> | Well since annevk is not here, take it up with Ms2ger |
| 18:55 | <jgraham> | :) |
| 18:56 | <Ms2ger> | ? |
| 18:56 | <AryehGregor> | I don't think we should actually test it, but only because it would make almost all browsers fail every assert_throws(). |
| 18:56 | <AryehGregor> | Which is obnoxious clutter. |
| 18:56 | <Ms2ger> | I agree |
| 18:57 | <AryehGregor> | But let's leave it commented out with a note to enable it once the latest version of everyone converges on it. |
| 18:57 | <Ms2ger> | And not even because it's Gecko which fails :) |
| 18:57 | <jgraham> | It would be nice to put it back in if people start to get it right |
| 18:57 | <jgraham> | But I am sure if I do that someone will complain |
| 18:58 | <jgraham> | I already get hate mail for fixing bugs (not really) |
| 18:58 | <jgraham> | (but I did cause confusion by fixing a bug that the Web Performance people were relying on) |
| 18:58 | <AryehGregor> | A harness bug? |
| 18:59 | <jgraham> | Yeah |
| 19:00 | <Ms2ger> | So, WebIDL claims e.name == "DOMException" |
| 19:01 | <AryehGregor> | I don't think anyone does that. |
| 19:02 | <AryehGregor> | We seem to have interop on the .name of a TypeError being "TypeError". |
| 19:02 | <jgraham> | Is that required by ES5? I forget |
| 19:02 | <AryehGregor> | But no interop on the .names of DOMExceptions or RangeExceptions. |
| 19:02 | <jgraham> | Really DOMExceptions should behave much like native Errors |
| 19:03 | <AryehGregor> | You know, assert_throws() really makes no sense. |
| 19:03 | <AryehGregor> | The mode where you pass an object doesn't actually do anything except verify that the .name attribute matches. |
| 19:03 | <AryehGregor> | Which is useless for anything but TypeErrors. |
| 19:04 | <AryehGregor> | DOM Range tests are littered with incorrect usages. |
| 19:04 | <AryehGregor> | Could we make it more useful? Like either allow only a string and special-case the error types we care about, or actually allow the passed object to do something useful? |
| 19:05 | <AryehGregor> | Like "for each property of the passed object, the thrown exception must have that property with the same value"? |
| 19:05 | <AryehGregor> | Also, the error text right now is confusing, because it doesn't actually say what part of the assertion failed. |
| 19:05 | <jgraham> | Hmm, where does the platform throw non-ES-Errors or non-DOMExceptions? |
| 19:06 | <AryehGregor> | DOM Range throws RangeExceptions. |
| 19:06 | <AryehGregor> | I'm pretty sure IndexedDB throws its own exceptions too. |
| 19:06 | <AryehGregor> | And maybe others. |
| 19:06 | <jgraham> | A RangeException isn't an instanceof a DOMException? |
| 19:07 | <jgraham> | Or is there some basic Exception type? |
| 19:07 | <Ms2ger> | No |
| 19:07 | <jgraham> | Oh. Who designed this platform? |
| 19:07 | <Ms2ger> | How about I kill RangeExceptions? |
| 19:08 | <jgraham> | Do browsers already support them? |
| 19:09 | <Ms2ger> | Gecko does, but I think I can convince sicking :) |
| 19:10 | <jgraham> | Can you convince him to kill IDBDatabaseException? :) |
| 19:10 | <sicking> | actually |
| 19:11 | <sicking> | the DOMException design is horrible, we need to abandon it |
| 19:11 | <jgraham> | Which part in particular? |
| 19:11 | <Ms2ger> | So you agree less classes with that design is good? :) |
| 19:11 | <sicking> | Ms2ger: no, the opposite |
| 19:12 | <sicking> | first off DOMExceptions aren't very javascripty |
| 19:12 | <Ms2ger> | The DOM isn't |
| 19:12 | <sicking> | we're trying to fix that though |
| 19:12 | <sicking> | normal javascript exceptions can be checked by just checking .type, or by using instanceof |
| 19:12 | <sicking> | they have one interface per exception type |
| 19:13 | <jgraham> | I don't mind many classes if there is some Exception type they all inherit from |
| 19:13 | <sicking> | jgraham: yup, there should be |
| 19:13 | <sicking> | second, the fact that DOMException is code based means that authors have to check both interface name and code number |
| 19:14 | <sicking> | unless we somehow manage to never have two specs use overlapping codes. So far we've failed at this |
| 19:15 | <sicking> | webidl is getting better exception support, we should use it |
| 19:15 | <Ms2ger> | Not for existing exceptions |
| 19:15 | <jgraham> | So the proposal is what? Kep it basically the same but with non-sucky inheritance models? |
| 19:15 | <jgraham> | *Keep |
| 19:15 | <jgraham> | Or add stuff to the existing API? |
| 19:15 | <sicking> | Ms2ger: why not? If we can do it in a backwards compat manner |
| 19:15 | <jgraham> | We can't really subtract stuff... |
| 19:16 | <sicking> | I think all we need is .code to remain backwards compat, and "e instanceof DOMException" |
| 19:17 | <sicking> | so just define new exception interfaces which all inherit from DOMException |
| 19:17 | <sicking> | and that have .code set to what DOMException uses now |
| 19:18 | <sicking> | and do the same for other exception interfaces if we think it's needed |
| 19:19 | <jgraham> | It sounds like it could work |
| 19:20 | <AryehGregor> | That sounds good. |
| 19:20 | <AryehGregor> | Except, what about if the exception was thrown in another window? |
| 19:20 | <AryehGregor> | Then instanceof breaks. |
| 19:20 | <jgraham> | AryehGregor: So I guess I need to fix up testharness.js in the meantime |
| 19:20 | <jgraham> | any particular API you like? |
| 19:20 | <AryehGregor> | I guess sicking didn't see: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12295 |
| 19:20 | <AryehGregor> | jgraham, one sec, I'm writing a patch. |
| 19:21 | <jgraham> | AryehGregor: I doubt I will do it right now :) |
| 19:21 | <sicking> | AryehGregor: that's already the case. And you can still check .type |
| 19:21 | <AryehGregor> | Hmm, right. |
| 19:22 | <AryehGregor> | But then .type is the only reliable piece of info, so why bother with the inheritance stuff? |
| 19:22 | <AryehGregor> | jgraham and Ms2ger, quick proposed patch: http://pastebin.com/TgX0YNyf |
| 19:23 | <jgraham> | AryehGregor: You have to be sure to check against the interface object in the right global scope |
| 19:24 | <jgraham> | which is not *usually* a problem |
| 19:24 | <AryehGregor> | How are you supposed to know what the right global scope is, in general-purpose code? |
| 19:24 | <jgraham> | Well that is an interesting question |
| 19:24 | <AryehGregor> | It's not usually a problem in the sense that it will very rarely come up, so nobody will code for it and they'll get inscrutable errors and assume browsers are crazy. |
| 19:24 | <jgraham> | istr that a goal of ES5 was to make that hard :) |
| 19:24 | <AryehGregor> | (which is what I did) |
| 19:24 | <AryehGregor> | (although I'd have figured it out sooner if Firefox matched other browsers here) |
| 19:26 | <jgraham> | AryehGregor: I don't think I like that approach |
| 19:27 | <AryehGregor> | My patch? |
| 19:27 | <jgraham> | Yeah |
| 19:27 | <AryehGregor> | The error messages are slightly confusing because they no longer mention the expected interface. |
| 19:27 | <AryehGregor> | That could be fixed easily, though. |
| 19:27 | <jgraham> | I think it makes things more magic rather than less |
| 19:27 | <AryehGregor> | Do you have a proposal for making things less magic without adding lots of verbosity to callers? |
| 19:27 | <jgraham> | Good question |
| 19:27 | <AryehGregor> | Do you think it's even possible to make things less magic? |
| 19:28 | <jgraham> | Well sure |
| 19:28 | <AryehGregor> | Especially if we want to be able to easily switch what we're testing in the future, if the spec for DOMException or such is changed? |
| 19:28 | <AryehGregor> | E.g., testing .name or .type or something. |
| 19:28 | <jgraham> | assert_throws_dom("code", exception_obj, func) for example |
| 19:29 | <jgraham> | like assert_throws("INVALID_REQUEST_ERR", DOMException, func) |
| 19:29 | <jgraham> | +_dom |
| 19:29 | <jgraham> | It is more verbose though |
| 19:29 | <AryehGregor> | How would that work for RangeExceptions? |
| 19:29 | <AryehGregor> | My approach isn't extensible at all, it's true. |
| 19:30 | <jgraham> | assert_throws_dom("SOME_CODE", RangeException, func) |
| 19:30 | <jgraham> | and it neatly solves the global problem by making the caller deal with it |
| 19:30 | <AryehGregor> | Hmm. |
| 19:30 | <AryehGregor> | Now that's a thought. |
| 19:31 | <AryehGregor> | Except, is it actually specced what global the thrown exception should be part of? |
| 19:31 | <AryehGregor> | If I get a Node object from another window, and call a method on it in this window, is the thrown exception from that window or this one? |
| 19:31 | <jgraham> | Oh, I remember running into that too |
| 19:31 | <AryehGregor> | Come to think of it, this must be why any non-Firefox browsers passed my tests. |
| 19:31 | <jgraham> | It's all good fun this :) |
| 19:32 | <AryehGregor> | I guess WebKit throws from the Node's window, and IE from the current window. |
| 19:33 | <AryehGregor> | So as a design goal, do we want users to be able to easily extend assert_throws() to support their own exceptions without forking the library? |
| 19:33 | <AryehGregor> | If so, then we should have it accept a callback to determine if the exception is correct. |
| 19:33 | <AryehGregor> | Then third parties can write their own wrappers that pass in a callback. |
| 19:34 | <AryehGregor> | But the core library can provide some convenience wrappers for DOM exception types that need to be shared between specs. |
| 19:34 | <jgraham> | Why do we need a callback |
| 19:34 | <jgraham> | ? |
| 19:34 | <AryehGregor> | Because the caller might want to verify arbitrary things about the exception. |
| 19:34 | <AryehGregor> | Since no two specs agree on what properties exceptions have to have. |
| 19:34 | <jgraham> | No, I don't think that's needed |
| 19:35 | <jgraham> | I think assert_throws should be about chacking that an exception of the right type was thrown |
| 19:35 | <AryehGregor> | For what definition of "type"? |
| 19:35 | <jgraham> | If you want to do something more complex, use assert_equals |
| 19:36 | <AryehGregor> | Then you have to write your own boilerplate try/catch with multiple asserts. |
| 19:36 | <jgraham> | Interface+code for dom exceptions, object type for ES Exceptions |
| 19:36 | <jgraham> | Yeah, but only once per exception type or so |
| 19:36 | <jgraham> | You probably don't need to do that every time you test an exception is thrown |
| 19:37 | <AryehGregor> | We can't test interface. We could test that all the expected interface members are present and have the right types, I suppose. |
| 19:37 | <AryehGregor> | Anyone want to write a WebIDL parser in JS? :) |
| 19:37 | <jgraham> | instanceof tests interfaces |
| 19:37 | <AryehGregor> | Not reliably, because of the cross-window problem. |
| 19:37 | <jgraham> | at least it tests what I meant when I said interafces |
| 19:38 | <jgraham> | The cross-window problem is a problem, I agree |
| 19:38 | <AryehGregor> | I just removed instanceof checks from testharness.js because it was causing mass spurious test failures in WebKit. |
| 19:38 | <jgraham> | But the solution is probably to fix the browsers to agree on the right behaviour |
| 19:38 | <AryehGregor> | In the long term, maybe, but that doesn't help us for the present. |
| 19:39 | <AryehGregor> | I agree that testing instanceof is in principle ideal, but I don't think it's practical. |
| 19:39 | <jgraham> | In the present I would like to keep using the interfaces until people complain louded |
| 19:39 | <jgraham> | *louder |
| 19:39 | <AryehGregor> | Unless we can figure out how to work around browser bugs. |
| 19:39 | <jgraham> | Then maybe have some way to use the string representation |
| 19:39 | <AryehGregor> | That's not standardized. |
| 19:40 | <jgraham> | Does it work? If it does then it ought to be standardised |
| 19:40 | <jgraham> | and is good enough |
| 19:40 | <AryehGregor> | No, every browser has a different string representation. |
| 19:40 | <AryehGregor> | My mockup tests that e[code] == myinterface[code] and e.code == myinterface[code]. That actually works reasonably reliably in all browsers. |
| 19:40 | <AryehGregor> | I don't think we have interop on anything more. |
| 19:41 | <AryehGregor> | (for DOMException and RangeException) |
| 19:41 | <AryehGregor> | It's also what assert_throws tests right now for DOMException, right? |
| 19:41 | <AryehGregor> | Although not RangeException. |
| 19:42 | <AryehGregor> | The current implementation is totally broken, anyway. The DOMException case generates confusing error messages, and the non-DOMException case makes no sense (object is passed and then only one hardcoded property is tested and this isn't documented anywhere). |
| 19:43 | <AryehGregor> | Plus also generates confusing error messages. |
| 19:43 | <AryehGregor> | My proposed patch is backward-compatible, has succinct syntax for the caller, and generates better error messages, plus is already written. |
| 19:44 | <jgraham> | Nevertheless |
| 19:44 | <jgraham> | I think it is the wrong approach |
| 19:44 | <jgraham> | Since it makes the unerlying problem (the methhod is too magic) worse rather than better |
| 19:45 | <AryehGregor> | I don't think the method being magic is a problem, and if it is, we can break out the magic parts into a separate convenience function and expose the non-magic parts separately. |
| 19:45 | <AryehGregor> | What's wrong with the callback idea, then? |
| 19:46 | <jgraham> | I also think it might be possible to hack around the frame bug. The stringification of the interface objects is quite standard I expect |
| 19:47 | <AryehGregor> | Hmm, that's a thought. |
| 19:47 | <AryehGregor> | Although it's orthogonal. |
| 19:47 | <jgraham> | So one can say "pass in the interface object in the frame that generates the caller" and we can look up the same object in the local window |
| 19:48 | <AryehGregor> | The string representation actually isn't very standard. |
| 19:48 | <AryehGregor> | I mean, you can just special-case it. |
| 19:49 | <AryehGregor> | WebKit does function DOMException() { [native code] }, everyone else is [object DOMException]. |
| 19:50 | <AryehGregor> | I wish there were a better way to get the actual interface object, though. |
| 19:50 | <AryehGregor> | s/better // |
| 19:50 | <AryehGregor> | . . . still, that's orthogonal. |
| 19:50 | <jgraham> | Well that sucks |
| 19:50 | <AryehGregor> | Insofar as I would like to fix the DOM Range tests so that they actually work, and cannot do that with the current implementation of assert_throws(), what do you suggest I do? |
| 19:51 | <AryehGregor> | Since you don't want me to special-case RangeException the way DOMException is special-cased. |
| 19:51 | <AryehGregor> | I mean, look at it this way. If you rewrite it to some generalized form, you're going to have to support old callers anyway. |
| 19:51 | <AryehGregor> | So is it really a big deal to support old callers using RangeException as well as DOMException? |
| 19:52 | <AryehGregor> | I'd like to fix the DOM Range tests right now, and I can't without fixing assert_throws() to actually sanely accept non-DOMException inputs. |
| 19:52 | <jgraham> | For now could you just add RangeException in the most non-invasive way posible whilse I think about it? |
| 19:52 | <jgraham> | *possib;e |
| 19:53 | <AryehGregor> | Well, if I'm allowed to refactor assert_throws() in unrelated ways at the same time to improve its error reporting, that would be my patch minus the TypeError stuff. :) |
| 19:53 | <jgraham> | Sure, but don't be too surprised if I change it again :) |
| 19:53 | <AryehGregor> | As long as you don't break back-compat without telling me. |
| 19:54 | <AryehGregor> | Also, it just occurred to me: |
| 19:54 | <AryehGregor> | In most cases, the exception will actually be from the current window. |
| 19:54 | <AryehGregor> | So we can test that if e instanceof Object, e instanceof DOMException (or whatever) also. |
| 19:54 | <AryehGregor> | Like assert(e instanceof DOMException || !(e instanceof Object), ...) |
| 19:54 | <AryehGregor> | Not perfect, but better than nothing. |
| 19:55 | <jgraham> | Maybe |
| 19:55 | <jgraham> | It is times like these that I hate the CaJa people |
| 19:58 | <AryehGregor> | CaJa? |
| 19:59 | <jgraham> | http://en.wikipedia.org/wiki/Caja_project |
| 20:00 | <AryehGregor> | . . . why do you hate them? |
| 20:00 | <jgraham> | They were the main drivers behind requirments on it being impossible to get at the global object |
| 20:00 | <AryehGregor> | Oh. |
| 20:01 | <AryehGregor> | According to that page, they restrict themselves to a subset of JS anyway, so why do they care? They can just leave out the way to get at the global object. |
| 20:01 | <jgraham> | I don't really recall |
| 20:01 | <jgraham> | Possibly they wanted the main lanuage to enforce more of their invariants for them |
| 20:02 | <jgraham> | *language |
| 20:02 | <jgraham> | Or maybe it is hard to enforce by restricting features |
| 20:05 | <AryehGregor> | Oh . . . Firefox breaks on the assumption that it will be an instanceof Object/DOMException on the same windows. |
| 20:05 | <AryehGregor> | Sigh. |
| 20:06 | <gsnedders> | Basically nothing around the existance of multiple globals is speced |
| 20:09 | <gsnedders> | jgraham: Check [[Class]] of the exception object? |
| 20:15 | <AryehGregor> | jgraham, okay, pushed. |
| 20:16 | <AryehGregor> | Tell me if you want to break it. |
| 20:16 | <AryehGregor> | (so I can fix the DOM Range tests) |
| 20:21 | <AryehGregor> | Ack. |
| 20:22 | <AryehGregor> | Ms2ger, you know that the RangeException removal breaks compat, right? |
| 20:23 | <AryehGregor> | And tests? |
| 20:23 | <AryehGregor> | What's the reasoning for that? |
| 20:24 | <AryehGregor> | I mean, granted that it shouldn't have existed in the first place, but it does, and everyone implements it. |
| 20:25 | <Ms2ger> | I think it's worth trying to kill it |
| 20:26 | <AryehGregor> | Why? There are vastly more horrible things we don't bother trying to kill. |
| 20:26 | <AryehGregor> | Do you think you have implementer buy-in? |
| 20:26 | <AryehGregor> | I really don't see it as worth it. |
| 20:34 | <AryehGregor> | Ms2ger, we should at least put an XXX in the spec. |
| 20:34 | <AryehGregor> | If you want to keep it this way, though, I'll update the tests. |
| 20:37 | <sicking> | Ms2ger, AryehGregor: I think a better solution is to create two new exceptions which both inherit from RangeException. This would follow the better new WebIDL pattern and be backwards compatible |
| 20:38 | <AryehGregor> | As far as my tests go, that would be the same as the status quo ante, and I'm fine with it. |
| 20:38 | <sicking> | we *might* even be able to get away with making the new exceptions not inherit RangeException or have .code, but that would break backwards compat |
| 20:38 | <AryehGregor> | Although that pattern does break confusingly in the presence of multiple globals. |
| 20:38 | <sicking> | AryehGregor: no more or less than current behavior |
| 20:39 | <AryehGregor> | Well, with the current behavior the only way to more-or-less reliably test that it's the right error code is something like e.code == e.INVALID_NODE_TYPE_ERR, which happens to sidestep the interface issue. |
| 20:40 | <AryehGregor> | Your way would encourage authors to do e instanceof InvalidNodeTypeException or whatever the case may be, which will break in weird corner cases. |
| 20:40 | <AryehGregor> | Currently there's no real reason to do e instanceof RangeException, it's not realistically going to pass e.code == e.INVALID_NODE_TYPE_ERR otherwise. |
| 20:40 | <gsnedders> | AryehGregor: And what do you do about the Object/Array case? |
| 20:40 | <AryehGregor> | gsnedders, what? |
| 20:41 | <gsnedders> | AryehGregor: {} instanceof otherglobal.Object returns false |
| 20:41 | <gsnedders> | AryehGregor: This behaviour is consistent with everything in JS varying on globals |
| 20:41 | <AryehGregor> | On an unrelated note: I guess there's no way in hg to just throw away my local commits, like git rebase --hard some_commit && git pull? |
| 20:42 | <AryehGregor> | gsnedders, well, yeah. So I'm saying instanceof is broken and we shouldn't encourage authors to rely on it. |
| 20:42 | <sicking> | AryehGregor: Actually, right now you should both check |e instanceof DOMException && e.code = e.INVALID_...| |
| 20:42 | <AryehGregor> | sicking, you should, but the e instanceof DOMException part is superfluous in practice. |
| 20:42 | <sicking> | AryehGregor: but we don't need to encourage people to use instanceof. We can just tell them to use .type |
| 20:42 | <sicking> | AryehGregor: it's not, there are multiple exception types floating around |
| 20:43 | <AryehGregor> | Yeah, but how many of them have an error code called INVALID_NODE_TYPE_ERR? |
| 20:43 | <sicking> | AryehGregor: SVGException, RangeException, DOMException, I'm sure there are more |
| 20:43 | <sicking> | hmm... |
| 20:43 | <gsnedders> | AryehGregor: But it's not broken, they're fundementally different objects |
| 20:43 | <AryehGregor> | If authors should rely on .type, why define the extra interfaces at all? |
| 20:43 | <sicking> | that is a good point actually |
| 20:43 | <gsnedders> | AryehGregor: Someone could've mutated the object in one global scope but not another |
| 20:43 | <sicking> | AryehGregor: to follow javascript patterns |
| 20:43 | <AryehGregor> | Well, I guess that's a fair reason. |
| 20:44 | <sicking> | AryehGregor: not all code crosses globals |
| 20:44 | <AryehGregor> | Yeah, very little does, which is why the bug will be extremely confusing when it happens. |
| 20:44 | <gsnedders> | AryehGregor: The point of instanceof is to tell whether something is in the prototype chain, and hence any property that exists on an object that instanceof returns true for exists on that object. You're violating that semantic with the behaviour you want. |
| 20:44 | <AryehGregor> | Okay, so is there any way in hg to just throw out some local commits, or do I have to reclone? |
| 20:45 | <AryehGregor> | gsnedders, I didn't say I wanted it to behave differently, I just said authors should avoid it. |
| 20:45 | <sicking> | i agree that instanceof is problematic. But the way we're heading now is bad too. And checking .type seems to solve all problems |
| 20:45 | <AryehGregor> | Yeah, a .type property would be great if everyone implemented it. |
| 20:45 | <AryehGregor> | Of course, so would a .name property, or any other property, if everyone implemented it consistently . . . |
| 20:45 | <AryehGregor> | But I'm fine with ES5 compat. |
| 20:45 | <sicking> | err.. |
| 20:45 | <sicking> | sorry, it's called .name actually |
| 20:45 | <AryehGregor> | Oh. |
| 20:45 | <AryehGregor> | Well, that's convenient, isn't it? |
| 20:45 | <sicking> | i don't know why i keep thinking it's .type |
| 20:46 | <AryehGregor> | That's what the spec already says, then. |
| 20:46 | <AryehGregor> | Other than the extra interfaces. |
| 20:46 | <gsnedders> | AryehGregor: http://stackoverflow.com/questions/4172753/how-to-get-rid-of-some-changeset-in-hg |
| 20:46 | <AryehGregor> | sicking, what do you think about Ms2ger's change to get rid of RangeException entirely? Do you think Gecko would do that? |
| 20:46 | <sicking> | AryehGregor: what does the spec say .name should be on current exceptions? |
| 20:47 | <AryehGregor> | sicking, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-name |
| 20:47 | <sicking> | AryehGregor: i'd be fine with trying to get rid of RangeException, but only if it's replaced with something better |
| 20:47 | <AryehGregor> | Well, actually that conflicts, right? |
| 20:47 | <sicking> | AryehGregor: so "DOMException" then? |
| 20:47 | <AryehGregor> | Because the ES way would have .name be IndexSizeErrException or something? |
| 20:47 | <sicking> | AryehGregor: that's not what i'm proposing |
| 20:47 | <AryehGregor> | No, like "INDEX_SIZE_ERR". |
| 20:47 | <sicking> | no |
| 20:48 | <sicking> | IndexSizeException is what i'd propose |
| 20:48 | <sicking> | all exceptions are errors, no need to include "Err" |
| 20:48 | <AryehGregor> | Okay, so you're proposing that browsers change the meaning of .name on DOMException? Because it already exists and has a different value from that. |
| 20:49 | <sicking> | AryehGregor: yup, that's what i'm proposing |
| 20:50 | <AryehGregor> | Well, no two browsers currently agree on the meaning of .name for DOMException, so I guess it's not too bad . . . |
| 20:50 | <AryehGregor> | Chrome gives "HIERARCHY_REQUEST_ERR", Gecko gives "NS_ERROR_DOM_HIERARCHY_REQUEST_ERR", Opera gives "Error", IE gives undefined. |
| 20:51 | <AryehGregor> | It makes me a bit less enthusiastic about the proposal. |
| 20:51 | <AryehGregor> | gsnedders, yeah, so as I expected, it's not supported. Yay hg, as usual. |
| 20:52 | <AryehGregor> | So what I have to do is wipe out the whole repo and make a new one. That's so much better than in git, where the commits would be accessible for the next few weeks until garbage-collected in case I wanted them. |
| 20:53 | <AryehGregor> | And of course, the clone command also changes hgrc, and possibly other things that I'm not aware of. |
| 20:55 | <AryehGregor> | Seems like there's no good bridge for git users who are forced to use Mercurial, only the other way around. |
| 21:03 | <jgraham> | AryehGregor: I think you can do waht you want with mq but that is deep magic to me |
| 21:04 | <AryehGregor> | mq is a separate queue on top of hg, not a way of managing hg commits, right? |
| 21:04 | <AryehGregor> | So it would only work if I didn't actually commit locally yet? |
| 21:05 | <Philip`> | There's a way to convert hg commits into mq patches, so you can edit them and re-commit them |
| 21:06 | <Philip`> | (See hg qimport --help) |
| 21:06 | <Philip`> | (I think) |
| 21:06 | <AryehGregor> | Personally, I'm still going to go with hating hg and wishing I could use git. |
| 21:08 | <jgraham> | I think in this case git is better |
| 21:09 | <AryehGregor> | I have yet to find any nontrivial case where I consider hg better. |
| 21:09 | <AryehGregor> | And I've been using it for a few months now. |
| 21:09 | <jgraham> | In general I have come over to the idea that git's more mutable history is better for team work than mercurial's desire to preserve everything |
| 21:10 | Philip` | likes Hg because it works better in trivial cases, and almost everything he does is trivial cases |
| 21:10 | <AryehGregor> | I don't find it works better in trivial cases. |
| 21:10 | <jgraham> | because the commits that you want to make locally are not usually the same as the ones you eant to share |
| 21:10 | <jgraham> | *want |
| 21:10 | <AryehGregor> | Well, I should say that git has sometimes gotten me into some crazy state where I have no idea what it's doing, but on the other hand, hg has eaten my data, so it's more than equal. |
| 21:10 | <AryehGregor> | git is certainly harder to understand. |
| 21:13 | <jgraham> | I wonder how easy it is to delete commits using the internal api |
| 21:13 | <jgraham> | The mercurial internal API turns out to be quite easy to understand |
| 21:48 | <jamesr> | heycam: yt? |
| 21:50 | <heycam> | hi jamesr |
| 21:51 | <jamesr> | are you in the web perf call or planning to dial in to the second half? |
| 21:51 | <heycam> | I'm going to dial in for the second half |
| 21:51 | <jamesr> | k, me too. i want to propose that we try to keep technical discussions on the mailing list and not the telecon |
| 21:51 | <jamesr> | but i'm not sure how that will go over |
| 21:51 | <jamesr> | what's your preference? |
| 21:51 | <heycam> | yes, I agree with that |
| 21:53 | <heycam> | I also agree I'm not sure how it will go over :) |
| 21:53 | <heycam> | there didn't seem to be too much push back when it was mentioned at the f2f |
| 21:53 | <jamesr> | philippe seemed skeptical later on in email |
| 21:53 | <heycam> | I guess it is up to the chairs, anyway |
| 21:54 | <heycam> | I think we may need to demonstrate that we can make good progress without having technical discussion on the calls |
| 21:54 | <jamesr> | yeah |
| 21:54 | <heycam> | i.e. drive mailing list discussion of issues |
| 21:54 | <jamesr> | guess the best thing is to lead by example |
| 21:54 | <heycam> | yep |
| 21:54 | <Hixie> | if you just don't call in... :-) |
| 21:54 | <heycam> | :) |
| 22:04 | <jgraham> | technical discussion in mail ++ |
| 22:06 | <jgraham> | (also I very occasionally read Web Perf. mail and I can't do that if it is hidden away) |
| 22:06 | <jgraham> | (as telecon) |
| 22:17 | <AryehGregor> | Hmm, Opera has non-standard default styles for <blockquote>. |
| 22:17 | <AryehGregor> | I should write some tests for HTML5's Rendering section. |
| 22:17 | <AryehGregor> | That would be useful. |
| 22:24 | <jamesr> | heycam: i'd be a lot happier if this discussion started on the mailing list |
| 22:24 | <jamesr> | and/or ended there |
| 22:24 | <jamesr> | i've just zoned uot |
| 22:24 | <heycam> | me too. this isn't being minuted very well either. |
| 22:25 | <AryehGregor> | CSS question: why does a <br> immediately after a <div> take effect, while one immediately before a <div> does not? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/962 |
| 22:26 | <AryehGregor> | Is this specced somewhere? IIRC, CSS doesn't have too much to say about <br>. |
| 22:26 | <AryehGregor> | (in that link, there's extra whitespace between "Foo" and "Bar", but not "Bar" and "Baz", in the browsers I tested in) |
| 22:27 | AryehGregor | looks in CSS 2.1 |
| 22:27 | <TabAtkins> | I think it's because of whitespace collapsing. |
| 22:27 | <TabAtkins> | That migh not make sense. |
| 22:27 | <jamesr> | here we go again |
| 22:28 | <AryehGregor> | "Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose." |
| 22:29 | <AryehGregor> | That's probably it, somehow. |
| 22:29 | <AryehGregor> | Although I don't know how. |
| 22:32 | <AryehGregor> | So it seems like the last <br> in a block box is eaten, but not the first. |
| 22:32 | <TabAtkins> | Yeah, that's it. The first <br> creates an empty linebox, but the linebreak is preserved (due to being generated by a <br>). The second <br>'s linebreak, though, is on the same line as "Bar". The third line box which would otherwise be created has no preserved whitespace, so it's killed. |
| 22:32 | <bfrohs> | AryehGregor: I've always see it as <br> moves the insertion point from the current location to the next line (but takes up no space). So "text<br><div></div>" would move the insertion point from end of "text" to a new line, and the div would be inserted there. Since <br> takes up no space, the div remains on that new line. However, with "<div></div><br>text", the <br> is moved onto the next line automatically because <div> is a block element. The |
| 22:32 | <bfrohs> | n, it adds an additional lines... and the text follows that. |
| 22:32 | <AryehGregor> | TabAtkins, ah -- that must be it. |
| 22:33 | <AryehGregor> | It's kind of weird. You wouldn't think of a newline as being part of any line box at all, really. |
| 22:33 | <AryehGregor> | Thanks. |
| 22:33 | <TabAtkins> | Np. |
| 22:33 | <TabAtkins> | Characters aren't allowed to exist outside of lineboxes, and \A is a character. |
| 22:33 | <AryehGregor> | bfrohs, also makes sense, but not really precise in the sense of CSS 2.1. |
| 22:33 | <AryehGregor> | Anyway, either way is good enough for me. |
| 22:34 | <bfrohs> | AryehGregor: Yeah, just how I've always made sense out of it in my head based on what browsers actually do ;) |
| 22:42 | <jamesr> | heycam: do you use anolis? |
| 22:43 | <heycam> | jamesr, I do not, but many other people here do |
| 22:43 | <heycam> | would you rather switch to that from my custom xslt thingo? |
| 22:43 | <jamesr> | yeah, or teach me how your xslt thing works |
| 22:43 | <heycam> | either way is fine with me |
| 22:44 | <heycam> | as long as the output looks nice :) |
| 22:45 | <heycam> | if you are more familiar with anolis I'm happy to switch to that |
| 22:45 | <jamesr> | k, then i'll try to construct a version of your most recent draft minus the native animation stuff, get it into a format anolis likes, and then push that to HG once i figure out how that works |
| 22:45 | <jamesr> | is the idea we'd check in the input and output to HG? |
| 22:45 | <heycam> | great, thanks! |
| 22:45 | <heycam> | I think so, so that we can view the final form document on http://dvcs.w3.org/ |
| 22:47 | <heycam> | jamesr, btw we'll probably be making some changes to align with the webkit version: https://bugzilla.mozilla.org/show_bug.cgi?id=647517 and https://bugzilla.mozilla.org/show_bug.cgi?id=647518 |
| 22:50 | <jamesr> | ah ok |
| 22:51 | <jamesr> | i could add in my text for those too |
| 22:52 | <heycam> | yeah, I think that's fine |
| 23:08 | <AryehGregor> | Plaintext e-mail has RTL in visual order, not logical? Really? |
| 23:09 | <TabAtkins> | Plaintext doesn't mean "see the bytes in order". It just means no styling. Bidi algorithms aren't styling. |
| 23:10 | <AryehGregor> | I guess I have to test. |
| 23:13 | <AryehGregor> | Testing turned out to be too tiresome, what with encoding issues, so I'll live in ignorance. |
| 23:13 | <AryehGregor> | There's such a thing as encoding RTL in visual order, although it makes no sense if you have to do line breaking. I just saw someone say that the convention for plaintext e-mail is visual rather than logical. |
| 23:14 | <AryehGregor> | I mean, plaintext e-mail does predate the Unicode RTL algorithm by a wide margin. |
| 23:14 | <TabAtkins> | Am I crazy, or is wikipedia completely unstyled now? |
| 23:15 | <AryehGregor> | You're crazy. |
| 23:15 | <TabAtkins> | Hm. |
| 23:15 | <AryehGregor> | (if it persists, #wikimedia-tech) |
| 23:15 | <TabAtkins> | Let's check another browser. |
| 23:18 | <TabAtkins> | Okay, my computer just went crazy and lost my network drive. |
| 23:42 | <TabAtkins> | My computer has gone totally crazy. Time to reboot, I guess. |
