| 00:00 | <Lachy> | Hixie, I think the contest needs a better prize |
| 00:00 | <Hixie> | like what? |
| 00:00 | <Hixie> | and yes, i agree |
| 00:01 | <Lachy> | hmm... well, a million dollars would be nice :-) But how about a JavaScript development book |
| 00:02 | <Dashiva> | How about a signed copy of the html5 spec (when it's done) :) |
| 00:02 | <jruderman_> | tour of google? |
| 00:02 | <Hixie> | Dashiva: i don't want to encourage people to consider my signature worth anything. |
| 00:03 | <Dashiva> | Not yours, the entire WG's |
| 00:03 | <Hixie> | lordy |
| 00:03 | <Lachy> | or alternatively, a voucher for an online store |
| 00:03 | <Hixie> | that would be scary |
| 00:03 | <annevk> | one of the five handwritten versions of the HTML5 :p |
| 00:03 | Hixie | ponders on the issue |
| 00:03 | <Dashiva> | We need something to put in a museum to document it all |
| 00:03 | <annevk> | we will also sell one to amazon for a billion dollars to buy off patents |
| 00:03 | <Hixie> | my concern is that if there's a prize with monetary value it becomes a whole legal issue that i'm not competent to deal with |
| 00:04 | <jruderman_> | rumor has it that if the prize is worth less than $5000 you don't have to deal with too much crap |
| 00:04 | Hixie | notices a google exercise ball has rolled into his cube and wonders where it came from |
| 00:04 | <Hixie> | jruderman_: oh? |
| 00:05 | <Dashiva> | I always imagined google would have other polygons than just simple cubes |
| 00:06 | <Philip`> | The number of sides of the polygon represents the status of the employee, and the people at the very top have rooms that are indistinguishable from circles |
| 00:06 | <Hixie> | i love that book |
| 00:06 | <Lachy> | Hixie, a signed copy of Bible5 ;-) http://lists.w3.org/Archives/Public/www-html/2007Jun/0008.html |
| 00:06 | <Dashiva> | Wasn't there going to be a movie? |
| 00:06 | <Hixie> | Lachy: :-P |
| 00:07 | <Hixie> | what's it called. flatworld? flatland? |
| 00:07 | <Dashiva> | Flatland, I think |
| 00:07 | <Hixie> | great book |
| 00:07 | <Philip`> | http://xahlee.org/flatland/index.html |
| 00:07 | <Dashiva> | I read it on gutenberg, worked surprisingly well |
| 00:07 | <Hixie> | oh the other problem with prizes is there are sixteen tests, and likely they'll be built from many more than 16 submissions :-P |
| 00:08 | <Lachy> | so how will the winner be decided? |
| 00:08 | <Lachy> | or were you intending to just say everyone who's test was included was a winner |
| 00:08 | <Hixie> | well currently everyone who ends up contributing a test that i use will be mentioned in the source |
| 00:09 | <Hixie> | but i could probably come up with some "best" test determination somehow |
| 00:09 | Lachy | needs to write a test |
| 00:09 | <Lachy> | any known bugs that don't have tests in there yet? |
| 00:09 | <Hixie> | not good ones |
| 00:10 | Philip` | wonders about the sibling-selector dynamic update bug he mentioned a while ago |
| 00:10 | <Hixie> | that's already tested at least twice, i believe |
| 00:11 | <Philip`> | Ah, good |
| 00:12 | <Lachy> | I came across a bug today in Firefox, but I don't think it qualifies due to the spec requirements (unless I can reproduce it without those parts) |
| 00:13 | <jruderman_> | Hixie: isn't the real prize that you can be almost certain that gecko and/or webkit developers will fix your bug? ;) |
| 00:15 | <Lachy> | at the very least, the winner should get a free upgrade of their favourite browser :-) |
| 00:15 | <Dashiva> | The winner gets to choose the code name for Firefox 4 |
| 00:16 | <Hixie> | jruderman_: that's what i figured, but apparently people want more! |
| 00:17 | kingryan | is going to start a pool to take bets on which browser passes it first and when |
| 00:17 | <Philip`> | Dashiva: There's http://www.flatlandthemovie.com/ and http://www.flatlandthefilm.com/ (I'd only heard of the second one before now) |
| 00:17 | Lachy | votes Opera |
| 00:18 | Philip` | votes Konqueror |
| 00:18 | <Dashiva> | Probably same as for acid2 :) |
| 00:18 | <Lachy> | (I wonder if I'm inelible for this pool, since I work for Opera?) |
| 00:18 | <kingryan> | Lachy, Philip`: yeah, but how long will it take? :) |
| 00:18 | <Lachy> | *ineligible |
| 00:19 | <Dashiva> | Opera passes acid3 in May 2009 |
| 00:20 | <Philip`> | kingryan: 2008-08-27T16Z |
| 00:20 | <Philip`> | (for development builds) |
| 00:21 | <Dashiva> | Pssh, those don't count. If you can't do it without breaking the web, it's cheating :) |
| 00:21 | <Lachy> | My guess is the next major version of Opera that ships after 9.5 (currently in beta) |
| 00:22 | <kingryan> | of course, we don't know when the test itself will be done yet |
| 00:22 | <kingryan> | nor what specifically it will test |
| 00:22 | <Lachy> | we know about 84% if the tests |
| 00:22 | <Lachy> | s/if/of/ |
| 00:23 | <Philip`> | Dashiva: Okay, then I'll say 2008-12-09T11Z for a released build |
| 00:23 | <Philip`> | Oops, I got confused by timezones, I meant 2008-12-09T12Z |
| 00:25 | <Lachy> | Philip`, guesses should be down to millisecond precision :-) |
| 00:27 | <Philip`> | Lachy: That would be too hard to judge - there might be two people guessing correctly to the nearest second, but the internet latencies and FTP timestamp imprecisions would make it too hard to tell them apart |
| 00:27 | <kingryan> | second precision is probably enough :) |
| 00:29 | <jgraham> | Hmm. I guess webkit passes first, but neither Webkit nor Gecko are at the right point in their release cycle to ship soon... |
| 00:29 | <Philip`> | Could you give me a couple of weeks before I settle on the minute and second portions of my predictions? |
| 00:29 | <jgraham> | Maybe IE8 will astound everyone :) |
| 00:30 | <Lachy> | if the time is for the final release build that passes the test, then all votes need to be in before any preview releases are available |
| 00:30 | <Philip`> | Lachy: Can you give that vote deadline in seconds please? |
| 00:31 | <Hixie> | how do you define "preview releases"? |
| 00:32 | <Lachy> | any publicly available build that passes the test |
| 00:32 | <Philip`> | jgraham: It'd be interesting to know how many fixes Firefox 3.1 might include |
| 00:32 | <Lachy> | including nightlies |
| 00:32 | <Hixie> | Philip`: so... it looks like safari and firefox aren't changing their path construction to ignore the CTM as per spec |
| 00:32 | <Hixie> | Philip`: so i guess i'll have to change the spec |
| 00:32 | <Hixie> | Philip`: any advice on this matter? |
| 00:34 | <jgraham> | Philip`: Are the Mozilla folks planning to release 3.x versions? |
| 00:35 | <annevk> | http://www.google.com/search?q=%22firefox+3.1%22 |
| 00:36 | <Philip`> | Hixie: Seems sensible - I'd expect the most complex bit would be describing how strokes are transformed (I think Firefox and Safari do it the same, which is helpful), and maybe issues with pattern fill transforms, and I'm not sure what else |
| 00:37 | <Hixie> | can you elaborate on those? |
| 00:38 | <gavin> | jgraham: what do you mean? |
| 00:38 | <gavin> | 3.0.x security releases are planned |
| 00:38 | <Lachy> | Hixie, you got a response on reddit. |
| 00:38 | <Philip`> | jgraham: I'd hope so, because Moz2 (presumably for FF4) sounds like a potentially risky step and it'd be nice to get some intermediate improvements :-) |
| 00:38 | <gavin> | but there are no plans for "major minor" releases, as in 3.1 |
| 00:39 | <jgraham> | gavin: Yeah, that's what I had thought |
| 00:39 | <gavin> | the release after 3 is most likely to be 4, in my opinion |
| 00:39 | <gavin> | subject to change, IANAL, etc, etc ;) |
| 00:40 | <jgraham> | gavin: which means, to return to the original context, that a released gecko won't pass acid 3 for several years |
| 00:40 | <gavin> | several years? |
| 00:41 | <jgraham> | since mozilla 2 is unlikely to be quick :) |
| 00:41 | <gavin> | I don't think anyone really knows when the next gecko release will be |
| 00:41 | <gavin> | it might be 1.9.1 |
| 00:42 | <Philip`> | Hixie: The CTM's scale/rotation is applied to the stroke lines when stroke() is called, so e.g. rect(...); scale(n, n); stroke(); makes the lines n times wider |
| 00:43 | <Philip`> | Hixie: and http://tinyurl.com/2bfvog has a more interesting interaction of stroke and rotation/scale |
| 00:44 | <Philip`> | (Translations have no effect) |
| 00:44 | <jgraham> | gavin: Well FF2 shipped in october 2006 which is, I guess, roughly an 18 month release cycle for FF2-3. Wildly extrapolating into the future, I conclude that "several years" was probably a slight overstatement but "not soon" is probably accurate |
| 00:45 | <Hixie> | Philip`: o_O |
| 00:45 | <gavin> | a 1.9.1-based release could be pretty soon |
| 00:45 | <gavin> | more of a FF1.5-FF2 timeframe |
| 00:46 | <Hixie> | Philip`: well that's just fucking _weird_ |
| 00:47 | <Philip`> | (Hmm, I think I didn't actually test that Safari acts the same as Firefox in those cases) |
| 00:48 | <Philip`> | Hixie: Maybe ask e.g. Cairo developers if there's a relatively straightforward explanation of how their strokes are rendered? |
| 00:48 | <Philip`> | or leave it as implementation-defined behaviour :-) |
| 00:49 | <Philip`> | or at least don't worry much about it now since it's not as important as just applying the CTM to points at the right times |
| 00:50 | <fredrikh> | Hixie: speaking of paths, the arcTo specification in HTML5 seems to disagree with postscript and CG on one point |
| 00:50 | <Hixie> | fredrikh: send mail :-) |
| 00:51 | <Philip`> | fredrikh: Maybe see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-July/012117.html first in case that mentions it already :-) |
| 00:51 | <fredrikh> | Philip`: yeah, that's what i'm talking about :) |
| 00:55 | <Philip`> | Hixie: About pattern fills, I have no idea how it's implemented already, but I guess it'd do something like use the current CTM at the time where fill() is called (so fillStyle=createPattern(...); rect(...); scale(n, n); fill(); would let you scale the pattern without affecting the path) or something |
| 00:55 | <Philip`> | I should probably try testing that some day (not today) to see what happens... |
| 00:56 | <kig> | Philip`: that works in firefox and safari |
| 00:56 | <Hixie> | Philip`: k |
| 00:56 | <Philip`> | kig: The pattern thing? |
| 00:56 | Hixie | mumbles something about all this being way over his head |
| 00:56 | <kig> | but it's a hack because transforms change the stroke |
| 00:57 | <Philip`> | kig: Ah, okay, thanks |
| 01:01 | <kig> | (how i'm doing it in the SVG renderer is: setup path transform, create path, setup fill pattern transform, fill, setup stroke pattern transform, tweak ctx.lineWidth, stroke) |
| 01:01 | <Philip`> | Hixie: Anything I can help with (preferably not something very complex since I only barely know enough to pretend to know more than I really do)? :-) |
| 01:01 | <Philip`> | kig: Does that break when there's a non-uniform scale? |
| 01:01 | <kig> | yes |
| 01:02 | <Philip`> | Okay |
| 01:02 | <Philip`> | kig: Do you have ideas for redesigning the canvas API in a backward-compatible way so that it actually makes sense? ;-) |
| 01:03 | <Hixie> | Philip`: review the new text when i'm done, i guess :-) |
| 01:05 | <kig> | Philip`: have a transformation matrix for gradient/pattern objects |
| 01:06 | <kig> | that's applied after determining which pixels to draw on, but before the actual drawing |
| 01:08 | <kig> | var g = createLinearGradient(...); g.setTransform(1,0,0,1,0,0); g.rotate(0.5); g.translate(20,50); g.scale(0.4, 2.6); g.transform(1,0.9, -0.9,1, 0, 0); |
| 01:10 | <Philip`> | g.save(); g.restore() or is that not needed? |
| 01:13 | <kig> | i don't really need those.. |
| 01:15 | <Philip`> | This doesn't seem useful for linear gradients because you can just manually apply the transform to the two end points |
| 01:15 | <kig> | radial gradients on the other hand |
| 01:16 | <Philip`> | Radial gradients with non-uniform scaling? |
| 01:16 | <Philip`> | (I can't think of any other cases where it'd matter) |
| 01:17 | <kig> | and if you don't have it for linear gradients, you need a fork in the fill/stroke-path to create a new linear gradient based on the old one whenever you need to transform it.. |
| 01:19 | <kig> | the "not really possible currently" thing is stroking with a pattern/gradient that has non-uniform scale |
| 01:20 | <kig> | and/or shear |
| 01:22 | <kig> | fwiw, cairo already has cairo_pattern_set_matrix |
| 01:23 | Philip` | wonders if Quartz(?) has something similar |
| 01:23 | Philip` | wonders if Opera's thing has a name at all |
| 01:24 | <kig> | quartz has pattern matrix, specified at pattern creation time(?) |
| 01:27 | <fredrikh> | Philip`: QBrush, if it uses Qt in its canvas implementation |
| 01:28 | <fredrikh> | and it supports that as well |
| 01:32 | <fredrikh> | (opera, that is) |
| 02:14 | <jwalden> | Hixie: any chance you could change tests 31 and 32 to handle error reporting the usual way instead of giving no error messages if the test fails? |
| 02:16 | <Hixie> | done |
| 02:18 | <Hixie> | it's very sad, i haven't even received a single usable suggestion yet for acid3 |
| 02:18 | <jwalden> | you, sir, are a gentleman and a scholar |
| 02:19 | <jwalden> | I could write up <http://bugs.webkit.org/show_bug.cgi?id=16690>; into a test, although pedantically speaking that's probably better as part of the test HTML |
| 02:21 | <Hixie> | you couldn't write it into a single JS function |
| 02:21 | <jwalden> | I could, I'd just have to modify the acid3 DOM |
| 02:22 | <jwalden> | Hixie: 32, |captureCount| is undefined |
| 02:22 | <Hixie> | fixed |
| 02:23 | <Hixie> | jwalden: you couldn't write it into a single JS function without something else as well, such as changing the markup before the test runs |
| 02:23 | <Hixie> | jwalden: but i'd rather not do anything that can't be done from a single JS function |
| 02:23 | <jwalden> | yeah |
| 02:23 | <jwalden> | oh, true |
| 02:23 | <Hixie> | http://www.hixie.ch/tests/evil/acid/003/competition/ |
| 02:24 | <Hixie> | Philip`: http://www.whatwg.org/specs/web-apps/current-work/index-diff is the diff of the changes for the path stuff |
| 02:24 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/index-diff#the-2d |
| 02:25 | Philip` | will look tomorrow since he has to sleep now |
| 02:25 | <Hixie> | k |
| 02:25 | <Hixie> | nn |
| 02:26 | <Lachy> | Hixie, where will the final test be hosted and publicised? on WaSP again? |
| 02:26 | <Hixie> | that's still being figured out, but yeah, basically |
| 02:30 | <Lachy> | ok. I gotta go to bed and hope I don't sleep in tomorrow morning (I've set 2 alarms). |
| 02:30 | <Lachy> | I can't be late for work again. cya |
| 02:30 | <Hixie> | heh |
| 02:30 | <Hixie> | nn |
| 02:30 | <jruderman_> | any good acid3 competition submissions so far? |
| 02:30 | <Hixie> | jruderman_: none |
| 02:31 | <jruderman_> | oh, you said that 13 minutes ago |
| 02:31 | <Lachy> | Hixie, I will try to get one in by the end of the week |
| 02:31 | <Hixie> | Lachy: you might have to try for 16 :-) |
| 02:31 | <Hixie> | jruderman_: it's very sad |
| 02:31 | <Lachy> | if you could send me a list of bugs, that would help :-) |
| 02:32 | <Lachy> | ok, really gotta go. cya |
| 02:32 | <Hixie> | i really have no known bugs |
| 02:32 | <Hixie> | if i did, i'd have written tests already |
| 02:34 | <Philip`> | Lachy: Only two alarms? I've got four set now... |
| 02:34 | Hixie | is glad he doesn't have to use alarms |
| 02:34 | <Hixie> | though i occasionally set an alarm for 5pm so i make sure to get to work before dinner |
| 02:35 | <jwalden> | heh |
| 02:38 | <jruderman_> | do either of these look interesting? https://bugzilla.mozilla.org/show_bug.cgi?id=2212 https://bugzilla.mozilla.org/show_bug.cgi?id=2056 |
| 02:40 | <jruderman_> | https://bugzilla.mozilla.org/show_bug.cgi?id=3655 |
| 02:40 | <jruderman_> | are css 3 selectors fair game? |
| 02:40 | <Hixie> | if you can find a way to test them from JS in a way you can reproduce in http://www.hixie.ch/tests/evil/acid/003/competition/ then please send them to ian⊙hc |
| 02:40 | <Hixie> | i have to go now |
| 02:40 | <Hixie> | (and yes, anything that matches those rules are fair game. selectors are widely tested in Acid3 already in fact.) |
| 02:40 | <Hixie> | gotta go now |
| 02:40 | <Hixie> | nn |
| 02:41 | <jruderman_> | k |
| 02:53 | <jwalden> | dangit dangit dangit |
| 02:54 | <jwalden> | okay |
| 02:54 | <jwalden> | test 31 is buggy |
| 02:55 | <jwalden> | the input it inserts into the page has no type attribute |
| 02:55 | <jwalden> | HTML4 says the default is text |
| 02:56 | <jwalden> | and <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-6043025>; clearly says that .click() isn't supported for inputs of type text |
| 02:56 | <jwalden> | Hixie: ^ when you get back |
| 02:56 | <jwalden> | if you get back tonight, that is |
| 03:00 | <jwalden> | hey, that exposes a webkit bug! |
| 03:01 | <jwalden> | seems click() isn't a noop on at least inputs with type="text" |
| 03:02 | <fantasai> | Does anyone know if "The DOM attributes height and width must return the rendered height and width of the image, in CSS pixels" is implemented? |
| 03:03 | <jwalden> | fantasai: <http://mxr.mozilla.org/mozilla/source/content/html/content/src/nsHTMLImageElement.cpp#275>; says Gecko does |
| 03:04 | <fantasai> | jwalden: does it get modified by CSS? |
| 03:04 | <fantasai> | e.g. if I set "width: 100px" on a 200px-wide image, does width return 100px or 200px? |
| 03:06 | <jwalden> | I'm guessing from reading nsFrame::GetContentRect that it probably does, but it's probably faster to write a testcase |
| 03:06 | <jwalden> | than to read the code |
| 03:09 | <fantasai> | k. If the spec doesn't say anything about a DOM attribute reflecting the content attribute, does that mean they are independent? |
| 03:10 | <jwalden> | no idea |
| 03:54 | <fantasai> | /w/window 4 |
| 04:12 | <jruderman_> | https://bugzilla.mozilla.org/show_bug.cgi?id=254144 might be a good test for acid3 |
| 04:13 | <jruderman_> | if it's justifiable using specs, which maybe it isn't |
| 07:40 | <Hixie> | jwalden: i think the spec could be read either way, but i've made it type=reset to avoid ambiguity |
| 08:49 | <Philip`> | Hixie: About the canvas shadow thing: see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011799.html :-) |
| 08:56 | <hsivonen> | zcorpan: the ns filtering warning is now triggered by attribute filtering, too |
| 08:56 | <hsivonen> | (it is a one-time warning) |
| 08:56 | <Lachy> | dammit. Slept in again cause my backup alarm was still set to Australian time :-( But not quite late for work though. |
| 09:23 | <hsivonen> | zcorpan: I fixed the HTML octet-stream thing. You have to force one of the HTML parsing modes, though, since XML is more likely to have a bogus type than HTML |
| 09:42 | <annevk> | Philip`, so not all transformations affect the current path? |
| 09:42 | annevk | didn't know that was the case |
| 09:44 | <hsivonen> | IIRC, Gecko has (had?) some stroke transformation weirdness with SVG. was that a Cairo thing or an SVG thing? |
| 09:49 | <Philip`> | annevk: Not entirely sure what you mean |
| 09:50 | <hsivonen> | is there a way to detect when a page is being redisplayed due to the user pressing Back? |
| 09:50 | <hsivonen> | in JS that is? |
| 09:51 | <hsivonen> | The v.nu UI script modifies the form onsubmit. when the user presses Back in Firefox, the form is unusable |
| 09:51 | <annevk> | http://krijnhoetmer.nl/irc-logs/whatwg/20080115#l-137 |
| 09:52 | <Philip`> | annevk: Oh - translations just don't affect the stroke shape of a path |
| 09:52 | <Philip`> | (The path itself still gets translated) |
| 09:53 | <Philip`> | (but then the stroke goes over that path, with just the stroke width (and some skewiness) affected by the CTM) |
| 09:53 | <OmegaJunior> | hsivonen: I wouldn't know |
| 09:53 | <OmegaJunior> | I can imagine comparing a timestamp in the page with a timestamp in javascript |
| 09:54 | <OmegaJunior> | but that has issues with caching proxies etc. |
| 09:56 | <hsivonen> | hmm. Is the form submission data built before or after the unload event? |
| 09:56 | <OmegaJunior> | Before |
| 09:57 | <hsivonen> | excellent |
| 09:57 | <hsivonen> | then I can modify the form onsubmit and modify it back onunload |
| 09:57 | <OmegaJunior> | Yes, or just modify it onunload, to prevent a second submit |
| 09:58 | <hsivonen> | I want to *allow* Back button plus second submit |
| 09:58 | <hsivonen> | that's the problem |
| 09:58 | <OmegaJunior> | Ah |
| 09:59 | <hsivonen> | I just want to make the GET URI parameters pretty by disabling fields that have an empty value |
| 09:59 | <OmegaJunior> | With some ajaxed handling you may find a lack of onunload. |
| 10:13 | <annevk> | hmm http://www.dreamhoststatus.com/2008/01/15/billing-issues/ |
| 11:38 | <mpt> | hsivonen, ah, shades of the "Bugzilla query.cgi URLs should be shortened" bug |
| 11:38 | <mpt> | Why not eat the unused parameters on the server and redirect? |
| 11:40 | <hsivonen> | mpt: because that would break the simplicity of request-response |
| 11:40 | <hsivonen> | mpt: I think I have it covered in JS now. (tested Firefox 2, Safari 3 and Opera 9.5 beta) |
| 11:42 | <Lachy> | Firefox seems to have a bug with moving elements between documents. I'll have to investigate that more thoroughly later and write a test case for acid3 if I can |
| 11:42 | <othermaciej> | hsivonen: Firefox has a (nonstandard) event when loading something from the back/forward cache, but on a back that doesn't get the special b/f cache treatment you get a load event instead (makes it kinda hard to use) |
| 11:43 | <othermaciej> | Lachy: moving elements between documents is not allowed, per official DOM specs |
| 11:43 | <Lachy> | really? Opera allows it |
| 11:43 | <othermaciej> | (WebKit supports it anyway due to compat requirements to emulate Mozilla) |
| 11:43 | <othermaciej> | (probably Opera for the same reason) |
| 11:44 | <othermaciej> | this and getAttribute("nonexistent") returning null instead of "" are our only two DOM 1 Core violations that I am aware of (both intentional for compat with teh Fox) |
| 11:44 | <hsivonen> | othermaciej: ok. thanks. I already addressed the issue using onunload, and the same codepath works for Gecko/WebKit/Opera. |
| 11:44 | <hsivonen> | othermaciej: do you happen to remember the name of the event? |
| 11:44 | <othermaciej> | I was going to suggest onunload |
| 11:44 | <othermaciej> | I don't remember |
| 11:45 | <hsivonen> | othermaciej: ok |
| 11:45 | <othermaciej> | using it would not work in Safari or Opera anyway |
| 11:45 | <Lachy> | Then, when using XHR to retrieve an XML document, obtaining the DOM from responseXML (which returns a Document), how is one supposed to move those elements into the DOM of the main document? |
| 11:45 | <annevk> | using importNode() |
| 11:45 | <othermaciej> | adoptNode() or something like that |
| 11:45 | <othermaciej> | it's a lame restriction |
| 11:46 | <Lachy> | ok. |
| 11:46 | <hsivonen> | also, making each node know their owner document seems an inefficient idea |
| 11:46 | <Lachy> | annevk, you should consider adding an example of that to the XHR spec. |
| 11:46 | <annevk> | feel free to write one |
| 11:46 | <Lachy> | ok, will do later |
| 11:47 | <othermaciej> | hsivonen: I think there's reasons beyond that which require every node to know their owner document |
| 11:47 | <othermaciej> | (even ones not currently in a document) |
| 11:47 | <othermaciej> | the DOM is not really designed for efficiency |
| 11:47 | <annevk> | so Firefox does it arguably we could test for it in Acid3 |
| 11:47 | <othermaciej> | otherwise it wouldn't expose child nodes as both a linked list *and* an array |
| 11:48 | <hsivonen> | I think in a Java environment it can even happen in practice that different trees are backed by different DOM impls. |
| 11:48 | <annevk> | the DOM also has all kinds of quirks such as CDATASection and EntityReference |
| 11:48 | <othermaciej> | (which results in a set of operations that can't possibly all be efficient) |
| 11:49 | <othermaciej> | (I think it may have even been proven with information theory that you can't make append, prepend, insert, remove, next, previous, and get nth all O(1) ) |
| 11:49 | <hsivonen> | I think it would be good to guarantee certain efficiency properties for central operations |
| 11:50 | <hsivonen> | like iterating over a children with increasing index |
| 11:50 | <Lachy> | hmm. importNode isn't tested in acid3. maybe I should look for bugs with that - its spec looks quite complicated |
| 11:50 | <othermaciej> | Safari and Mozilla have fundamentally different performance profiles |
| 11:50 | <hsivonen> | or document order traversal using firstChild/nextSibling |
| 11:50 | <othermaciej> | WebKit has a linked list internally so previousSibling/nextSibling are very fast and childNodes relies on a cache |
| 11:50 | <othermaciej> | Mozilla has an array internally so childNodes is fast and previousSibling/nextSibling rely on a cache |
| 11:51 | <othermaciej> | (though I think in many common cases WebKit's indexed access ends up being faster than Mozilla's anyway) |
| 11:51 | Lachy | wonders if it's possible to have a combined array/linked list data structure to get the best of both worlds |
| 11:51 | <othermaciej> | Lachy: not really |
| 11:52 | <othermaciej> | it might be possible to design a data structure where none of the operations I listed are worse than O(log N), but even that is very hard |
| 11:52 | <hsivonen> | exposing the index to app code seems ugly anyway (like charAt()). I think firstChild/nextSibling traversal looks better that way |
| 11:52 | <othermaciej> | using one or the other with a cache seems to be the best you can do |
| 11:52 | <Lachy> | it would make inserting into the array a pain, since you'd have to update the array indexes as well as the pointers from the previous and next objects |
| 11:52 | <othermaciej> | firstChild/nextSibling is easier to extend to a full preorder tree traversal |
| 11:53 | <othermaciej> | (internally in webkit we have a Node::traverseNextNode() method that gives you the next node in document order |
| 11:53 | <othermaciej> | it might be handy as a public API for JS someday |
| 11:53 | <othermaciej> | certainly easier to use than nonsense like TreeWalker |
| 11:53 | <hsivonen> | othermaciej: how does it distinguish between initial visit and revisit of a parent? |
| 11:54 | <othermaciej> | hsivonen: in preorder traversal you never revisit a parent |
| 11:54 | <othermaciej> | (document order == preorder) |
| 11:54 | <othermaciej> | or rather, whenever you run out of next siblings, you go up until you find an ancestor that has a next sibling and go there |
| 11:54 | <hsivonen> | othermaciej: depends on use case. when serializing, you definitely want the preorder travelsal to revisit |
| 11:56 | <othermaciej> | that can't be done with an equally simple API afaik |
| 11:56 | <othermaciej> | though a callback-driven API could do it with no more than one node's worth of internal state |
| 11:56 | <zcorpan> | JS has innerHTML for serializing... :) |
| 11:56 | <othermaciej> | (possibly an extra outermost container node, which our traverseNextNode handles) |
| 11:59 | <othermaciej> | but yeah, in a tree structure with parent pointers you can do just about any traversal of interest without either recursion or an explicit stack |
| 13:35 | <hsivonen> | Hixie: here's an idea for a test: have element in the DOM with an id attribute, replace the element with a different one with the same id attribute value, try to getElementById and see if you get the new element back (without spinning in the event loop in between) |
| 13:36 | <hsivonen> | my hypothesis is that the getElementById hash is inconsistent until event loop spin |
| 13:36 | gavin | would be surprised if that was the case in gecko |
| 13:37 | <hsivonen> | gavin: oh. then I'm seeing some other weirdness in my attempts to polish the Validator.nu UI |
| 13:38 | <hsivonen> | hmm. scratch that. |
| 13:39 | <hsivonen> | I'm seeing weirdness but I misdiagnosed it |
| 14:42 | <mpt> | hsivonen, the tooltip for "Encoding" refers to "the schema field above", but it's below |
| 14:43 | <mpt> | Also, I think you could get away with s/The * field //g |
| 14:44 | <mpt> | (capitalizing the next word in each tooltip as appropriate) |
| 14:44 | <mpt> | "Don't override" might be clearer as "As specified by the document" or similar |
| 14:45 | <hsivonen> | mpt: it's the wrong tooltip. I thought I had already pushed out a fix. (already fixed locally) |
| 14:45 | <hsivonen> | mpt: I'll make wording changes for the next iteration. thank you |
| 14:45 | <hsivonen> | afk |
| 14:46 | <mpt> | Yay for supporting https: URLs :-) |
| 18:04 | <gsnedders> | the py html5lib just calls the filters with, "treewalker = Filter(treewalker)". How does calling __init__ call __iter__? |
| 19:23 | <jgraham_> | gsnedders: I'm not quite sure what your question is, but __iter__ is automatically called when looping over an object |
| 19:24 | <jgraham_> | See http://docs.python.org/lib/typeiter.html for full details |
| 20:06 | <gsnedders> | jgraham_: but when does the looping happen? looking at the serialiser, all it calls is Filter(treewalker), and __init__ doesn't do any looping… |
| 20:14 | <Lachy> | gsnedders, your last email to www-archive wasn't clear whether your comments were aimed at James or Dean |
| 20:15 | <gsnedders> | Lachy: oops. just follow the "to" |
| 20:15 | <Lachy> | from what you wrote, I assume it was supposed to be aimed at Dean, despite directly responding to James |
| 20:16 | <Lachy> | yeah, I looked at that after I started reading and wondered why you were saying all those things to James |
| 20:18 | <Lachy> | It's strange how external floppy drives and CD drives were common in the early days, then they were integrated into computers for convenience, and now the MacBook Air is shipping only with an optional external drive. |
| 20:19 | <Lachy> | I guess Apple's Time Machine must work too well :-) |
| 21:00 | <Lachy> | Maybe we could distinguish between the language and the serialisation by calling them HTML (for the language) and HTMS (Hypertext Markup Serialisation) |
| 21:00 | <Lachy> | or Hypertext Markup Syntax |
| 21:15 | <jgraham_> | gsnedders: Look at filters/_base.py __init__ doesn't call __iter__ (that would be odd); it just adds a .source attribute to the filter pointing to the treewalker Then __iter__ returns an iterator over .source. Subclasses then alter the tokens produced by this iterator |
| 21:15 | <jgraham_> | (see e.g. filter/whitespace.py) |
| 21:15 | <gsnedders> | quite when is __iter__ controller? |
| 21:16 | <gsnedders> | what the ehll did I just type? |
| 21:16 | <gsnedders> | *hell |
| 21:16 | <gsnedders> | quite when is __iter__ called? |
| 21:16 | <gsnedders> | that makes more sense. |
| 21:16 | <jgraham_> | When you do something like "for x in y:" you call y.__iter__ |
| 21:17 | <jgraham_> | which has to return an object with a .next() method |
| 21:17 | <jgraham_> | In the html serializer it happens on line 103 |
| 21:17 | <jgraham_> | for token in treewalker: |
| 21:18 | <gsnedders> | jgraham_: ah, so it just applies all the filters then? |
| 21:19 | gsnedders | is finally making sense of this |
| 21:19 | <jgraham_> | Indeed. It's just a way of chaining things together |
| 21:20 | <gsnedders> | It finally makes sense! |
| 21:20 | <gsnedders> | thanks |
| 21:21 | <gsnedders> | jgraham_: actually, where is next() defined? |
| 21:22 | <jgraham_> | gsnedders: If you use yield it automatically does the right thing wrt .next() |
| 21:22 | <gsnedders> | ah |
| 21:26 | gsnedders | wonders whether to write his own RSS Profile |
| 21:40 | <Lachy> | gsnedders, why would you want to use RSS for anything, even if you wrote your own profile? Atom is better |
| 21:41 | <gsnedders> | Lachy: oh, I wouldn't. But as I can tell you, and anyone else who's read the spec can tell you, the spec is useless for implementing it from either a UA POV or an authoring POV. |
| 21:41 | <Lachy> | oh, so you want to write RSS5 |
| 21:42 | <gsnedders> | basically. |
| 21:42 | <gsnedders> | Probably ought to call it that. |
| 21:42 | <Lachy> | yeah, I'd wait for XML5 first, though. |
| 21:43 | <Lachy> | or you could spec the vocabulary and the processing requirements, leave parsing requirements for later |
| 21:43 | <gsnedders> | even <http://www.rssboard.org/rss-profile>; is too vague, and I disagree with some of the advice (despite being listed as one of the four contributors) |
| 21:44 | <gsnedders> | Lachy: peh, I'd just help with XML5 (though annevk advised me to revise for my exams, which start tomorrow) |
| 21:44 | <gsnedders> | Lachy: I could also do the HTML 5 solution so XML 1.0 or any later version |
| 21:44 | <Lachy> | RSS5 should handle all 10 versions of RSS from 0.90 to 2.0 |
| 21:45 | <Lachy> | note that they're all incompatible with each other too :-) |
| 21:45 | <gsnedders> | Lachy: the RDF and non-RDF ones need to be handled differently though |
| 21:45 | <gsnedders> | Lachy: (on top of the other incompatibilities) |
| 21:46 | <Lachy> | so, the important question is, what would RSS5 stand for? Rich Site Summary, RDF Site Summary or Really Simple Syndication? |
| 21:46 | <gsnedders> | Really Stupid Syndication |
| 21:46 | <Lachy> | LOL |
| 21:47 | <Dashiva> | Rather Silly Stuff |
| 21:47 | <Dashiva> | RSS5 is already known as Atom :P |
| 21:47 | <Lachy> | authoring conformance requirements would be easy, though. |
| 21:47 | <gsnedders> | (the sad thing is, I'm actually serious about that) |
| 21:47 | <gsnedders> | Lachy: author the subset of all RSS versions |
| 21:47 | <Lachy> | "Authors must not use this languague" |
| 21:47 | <Dashiva> | Lachy: Try writing a feed parser and you'll join the "RSS is evil and needs to be destroyed" club soon enough |
| 21:48 | <Lachy> | Dashiva, I'm already in the club |
| 21:48 | <gsnedders> | Lachy: the two are entirely equivalent, AFAIK |
| 21:49 | <Dashiva> | The largest common subset would probably end up being the <title> tag |
| 21:49 | <gsnedders> | I'm actually about to step-down from lead developer of SimplePie |
| 21:49 | <gsnedders> | Dashiva: no, it's content model and whether you have to sniff it depends on the version |
| 21:49 | <Lachy> | "Authors must produce RSS documents that conform to the requirements specified in The Atom Syndication Format. [RFC4287]" |
| 21:49 | <Dashiva> | gsnedders: Sure, but the tag itself is mandatory :) |
| 21:50 | <gsnedders> | Dashiva: and whether it is in a namespace (for RSS 0.90 or RSS 1.0) |
| 21:50 | <Dashiva> | Lachy: I love it |
| 21:50 | <gsnedders> | Lachy: Hmm, I wouldn't put that, probably only should (but must not conform to any version of RSS) |
| 21:51 | <Lachy> | unfortunately, future specifications can't retroactively change the conformace of documents with respect to the older specifications. So people will still be able to claim conformance |
| 21:51 | <Dashiva> | User agent conformance: Must pretend to handle it |
| 21:52 | <gsnedders> | "Authors MUST NOT use this language. The editor RECOMMENDS usage of The Atom Syndication Format. [RFC4287]" |
| 21:52 | <gsnedders> | (in RFC2119 document) |
| 21:52 | <Dashiva> | I didn't know recommends was a special word. Interesting. |
| 21:53 | <gsnedders> | alias for SHOULD |
| 21:54 | <Dashiva> | So, what does RSS5 say about hamburger vs pasta for dinner? |
| 21:55 | <gsnedders> | Pasta. |
| 21:55 | Lachy | made hamburgers |
| 21:55 | <Lachy> | ... real Aussie hamburgers (in Norway) |
| 21:55 | <gsnedders> | markp: I sent you an email a day of two about the remote base atom autodiscovery test-suite tests being broken, FYI |
| 21:56 | <gsnedders> | (seeming your always months behind emails, and it's nice to have test suites that work :)) |
| 21:57 | <Lachy> | Dashiva, the choice between burgers and pasta really depends on what you have to put on the burger |
| 21:57 | <Dashiva> | I have all the required condiments |
| 21:57 | <gsnedders> | "The editor RECOMMENDS eating pasta while implementing this specification. Lachlan Hunt RECOMMENDS eating hamburgers while implementing this specification." |
| 21:58 | <Lachy> | so long as there's beef, lettuce, tomato, onion, egg, pineapple and, most importantly, beetroot, you're set. |
| 21:58 | <Dashiva> | ... using pineapple on burgers is a criminal offense in many places |
| 21:59 | <Lachy> | pineapple is one of the 2 essential ingredients |
| 21:59 | <Lachy> | well, 3, cause I forgot to count beef. |
| 21:59 | <Dashiva> | And the buns? |
| 21:59 | <Lachy> | sure |
| 22:00 | <Lachy> | in fact, the only optional ingredients are egg and onion |
| 22:01 | <Lachy> | (I'm surprised you haven't objected to the beetroot yet. Most non-Aussies do) |
| 22:01 | <gsnedders> | "The food MUST contain beef, lettuce, tomato, pineapple, beetroot, as well as bread and MAY contain egg and onion." |
| 22:01 | <gsnedders> | (is that right?) |
| 22:02 | <gsnedders> | Lachy: oh, certainly, I'm objecting by not implementing Lachy's food REC |
| 22:02 | <Dashiva> | I'm gonna be as bold as to add ketchup |
| 22:02 | <Lachy> | Food5 |
| 22:02 | <Lachy> | of course, sauce is ok |
| 22:02 | <gsnedders> | Lachy: that'll cause endless flamewars. |
| 22:03 | <Dashiva> | The flamewars are even more pronounced when the flame-broiling is brought up |
| 22:03 | gsnedders | needs to go sleep, though |
| 22:03 | <Lachy> | nn |
| 22:03 | <gsnedders> | hope that I don't fail the English exam tomorrow afternoon for me :) |
| 22:04 | <Lachy> | I should start a burger shop called Burger5 |
| 22:04 | <Dashiva> | Then I'll compete with my newly founded Burgr |
| 22:08 | zcorpan | will do Semantic Burger 2.0 |
| 22:08 | <zcorpan> | with support for ARIA |
| 22:08 | <zcorpan> | and RDF |
| 22:10 | <Dashiva> | Really Delicious Food |
| 22:11 | <zcorpan> | Ain't Really ... hmm, can't come up with anything for "ARIA" |
| 22:11 | <othermaciej> | Lachy: ozzie burgers are funny |
| 22:12 | <othermaciej> | (never seen pineapple on them before though) |
| 22:15 | <Philip`> | Really Simple Burgers - you have two pieces of bread, and inside you can put either the filling or a recipe for the filling, and there is no way for someone to tell the difference until they try eating it |
| 22:16 | <Dashiva> | And they try to check, you flame them for doing it wrong! |
| 22:18 | <Lachy> | othermaciej, fyi, it's spelt "Aussie" (unless you're referring to Ozzie Ostrich) - but what's funny about them? |
| 22:20 | <othermaciej> | Lachy: I've seen Australians use the term, but they are probably the bad kind from not-the-city-you're-from and your rugby team can totally beat their rugby team |
| 22:21 | <Dashiva> | Did I mention my markup language can beat up your markup language? |
| 22:21 | jgraham_ | was about to object to pineapple+burger when he realised that his local pub does pineapple+stilton burger |
| 22:21 | <Molly__> | :: enters with an enormous piece of steak :: |
| 22:22 | <jgraham_> | Molly__: You can only come in if you're sharing |
| 22:22 | <Dashiva> | It's creepy when people enter the channel and join in on conversation that happened before they joined |
| 22:23 | <molly> | nah, there were rumors about a food fight in here |
| 22:23 | <molly> | I couldn't not join in :) |
| 22:23 | <molly> | jgraham : oh, I'll share |
| 22:23 | <jwalden> | mm, pineapple |
| 22:24 | <gsnedders> | molly: as long as you don't blame me. |
| 22:24 | <Lachy> | molly, we were discussing the merits of putting pineapple and beetroot on burgers, and the possibility of writing a Burger5 specificaion |
| 22:24 | <jgraham_> | Excellent, I'll have mine rare. |
| 22:24 | <gsnedders> | jgraham_: ewwww |
| 22:24 | <molly> | what's the Burger4 spec say? |
| 22:24 | <molly> | in re pineapple and beetroot? |
| 22:24 | <gsnedders> | molly: who needs Burger4? We just have Food4 and Burger1! |
| 22:25 | <molly> | but how will we style the burger? |
| 22:25 | <Philip`> | We need to do a survey of existing burgers to find the current best practices |
| 22:25 | <jgraham_> | Unless it's really nice in which case maybe some sort of steak tartare |
| 22:25 | <Lachy> | Well, the McOz was a success for McDonalds in Australia, and I think that was based on Burger3.2 |
| 22:25 | <molly> | what about all this buzz about BurgerML? |
| 22:25 | gsnedders | points molly at IM. |
| 22:26 | <gsnedders> | Am I emo, or not? |
| 22:26 | <gsnedders> | </totally_out_of_context> |
| 22:26 | <jgraham_> | <bun><meat origin="unidentified"/></bun> |
| 22:26 | <molly> | apparently, this allows for burger extensibility |
| 22:27 | <molly> | I'm not sure how this plays into the grander scheme of burger specs |
| 22:27 | <gsnedders> | molly: nonono, Burger5 needs to be an XML5 application. |
| 22:28 | <molly> | has that already been decided? |
| 22:28 | <gsnedders> | No, but the emo kid says so, so it must be true. |
| 22:28 | <molly> | I'm not sure how far we could extend a burger |
| 22:28 | <gsnedders> | Pineapple? |
| 22:28 | <molly> | I mean, a burger is a fairly well-defined entity |
| 22:29 | <molly> | is that an extension? |
| 22:29 | <jgraham_> | Presumably McDonalds could embed almost anything from ChemML into a burger |
| 22:29 | <molly> | or merely a style variation? |
| 22:29 | <molly> | jgraham now that worries me a bit |
| 22:29 | <molly> | hmm, do I detect a namespace concern? |
| 22:31 | <gsnedders> | well we definitely need to embed ChemML into Burgr5.0 |
| 22:32 | <annevk> | I think burgers are already addressed by http:// and tel: |
| 22:32 | <molly> | I don't like the idea of a meat element |
| 22:32 | <molly> | we need something more generic that would include non-meat ingredients |
| 22:33 | <gsnedders> | Food5? |
| 22:33 | <molly> | it's too presentational |
| 22:33 | <Philip`> | Use DTD modularisation to create a vegetarian profile |
| 22:33 | molly | thinks we might be on to something! |
| 22:33 | <jgraham_> | The meat affects the burger semantics for sure |
| 22:33 | <annevk> | <meat> is presentational? |
| 22:33 | <annevk> | hmm |
| 22:33 | <molly> | well you can have a veggie burger |
| 22:33 | <molly> | which doesn't have meat |
| 22:34 | <annevk> | sure |
| 22:34 | <jgraham_> | veggie burger is not a presentational variation on a proper burger by any strech of the imagination |
| 22:34 | <molly> | do we really need TWO elements or one more semantic element? |
| 22:34 | <annevk> | but <burger><meat/></burger> would be quite a different burger from <burger><salad/></burger> |
| 22:34 | <molly> | but it's called a veggie "burger" |
| 22:34 | <annevk> | in practice it turns out that more elements is better |
| 22:34 | <annevk> | see HTML <object> |
| 22:35 | <jgraham_> | Sure. <burger> would be the root element |
| 22:35 | <Philip`> | You could grow a chicken out of Quorn and then have a vegetarian chickenburger |
| 22:35 | <molly> | that's a fair point |
| 22:35 | <molly> | but wouldn't a veggie burger be a variant? |
| 22:35 | <molly> | so you'd have <meat variant="veggie" /> |
| 22:35 | <molly> | that doesn't make any sense |
| 22:36 | <molly> | I know, how about "filler" |
| 22:36 | <jgraham_> | <burger><bread type="bun"><cheese/><meat type="bacon"/><meat type="beef"/></bread></burger> |
| 22:36 | <molly> | <filler type="beef" /> |
| 22:36 | <Lachy> | as long as vege-burgers are not supported in BurgerML, I'm happy |
| 22:36 | <molly> | Lachy, why not? |
| 22:36 | <Lachy> | s/vege/vegie/ |
| 22:36 | <Lachy> | cause a buger isn't a burger without meat |
| 22:37 | <molly> | being a voracious carnivore myself I'd tend to agree |
| 22:37 | <molly> | but that's not true in a broader social context |
| 22:37 | <Lachy> | damn, I still didn't spell "veggie" right :-( |
| 22:38 | <molly> | now I'm hungry |
| 22:45 | molly | takes a big bite of her fully compliant and accessible Steak 2.2 |
| 22:51 | <Philip`> | Does anyone happen to know if an affine-transformed Bézier curve is equal to an untransformed Bézier between transformed control points? |
| 22:53 | <Philip`> | Oh, it clearly is since it's just a linear combination |
| 22:54 | <Philip`> | The arc/arcTo definitions are broken, though... |
| 22:57 | <Philip`> | (and rect) |
| 23:07 | <Philip`> | Hmm, Safari resets the path when you do restore() - I'd forgotten about that bug :-/ |
| 23:10 | <Philip`> | Also, it's funny to watch Opera attempting to do arcTo |
| 23:44 | <jwalden> | Hixie: you sure in test 5 you didn't mean for |substr(0, 1)| to be |substr(-1, 1)|? |
| 23:59 | <kig> | Philip`: write an arc/arcTo implementation that uses bezier curves :| |