| 00:17 | <AryehGregor> | By the way, for everyone here who told me about screen (Hixie? jgraham?): you rock. |
| 00:18 | <AryehGregor> | (or rather encouraged me to use it, it's not like I hadn't heard about it) |
| 00:21 | <Hixie> | screen is indeed awesome |
| 00:24 | <heycam> | if screen could fill my xterm scrollback buffers when i connect to it, rather than handle scrolling itself, i might use it more |
| 00:24 | <jcranmer> | screen is why I have such high IRC uptime |
| 00:24 | <Hixie> | i run my shells under emacs, so emacs takes care of it |
| 00:26 | <heycam> | i want an irc proxy so i can stay connected, but use an irc client locally. and i want the proxy to feed my client scrollback content too when i connect to it. (up to a reasonable amount, say a day or two. but to include excerpts outside this time period if my nick is mentioned.) |
| 00:27 | <Hixie> | why do you want a local client? |
| 00:27 | <heycam> | i am happy with x-chat |
| 00:28 | <heycam> | although i am quite happy reading my mail in mutt over ssh, a text-based irc client doesn't do anything for me for some reason |
| 00:32 | <Hixie> | i don't really know how to tell the difference... irc is text |
| 00:36 | <MikeSmith> | heycam: welcome back |
| 00:36 | <AryehGregor> | Text-based IRC clients annoy me too. |
| 00:36 | <AryehGregor> | I don't have a very good reason for this, though. |
| 00:37 | <AryehGregor> | I tried irssi but didn't feel it was worth it to learn how to use it. |
| 00:37 | <AryehGregor> | Oh, also I think it only let me use one window for all channels, which is unacceptable. |
| 00:37 | <AryehGregor> | I have a whole monitor with six channels tiled across it. |
| 00:39 | <MikeSmith> | also not clear to me what a text-based IRC client is |
| 00:39 | <MikeSmith> | means curses-based? |
| 00:39 | <AryehGregor> | One that runs in a terminal. |
| 00:39 | <AryehGregor> | Instead of a GUI app. |
| 00:39 | <MikeSmith> | ah |
| 00:39 | <othermaciej> | runs in a terminal, not GUI |
| 00:39 | <MikeSmith> | like irssi? |
| 00:39 | <MikeSmith> | ok |
| 00:39 | <othermaciej> | I am a long time GUI IRC client user |
| 00:39 | <othermaciej> | ever since X-Chat back in the day |
| 00:39 | <othermaciej> | now it's 100% Colloquy |
| 00:40 | <othermaciej> | even though Colloquy doesn't quite do everything I would like |
| 00:40 | <othermaciej> | it is usable and pretty to look at |
| 00:40 | <MikeSmith> | I recently switched from XChat to Colloquy and been very happy to have made the switch |
| 00:40 | <othermaciej> | also, WebKit |
| 00:40 | <MikeSmith> | yeah |
| 00:40 | <MikeSmith> | plus active developers |
| 00:40 | <othermaciej> | I feel compelled to demonstrate my patriotism |
| 00:40 | <MikeSmith> | and responsive developers |
| 00:40 | <MikeSmith> | on #colloquy |
| 00:41 | <AryehGregor> | I really dislike XChat. |
| 00:41 | <MikeSmith> | NoOneButMe++ |
| 00:41 | <MikeSmith> | akempgen++ |
| 00:41 | <AryehGregor> | Colloquy sounds great, too bad I use Linux. |
| 00:41 | <MikeSmith> | and of course xenon++++++++++ |
| 00:41 | <AryehGregor> | I'm pretty sure that's a syntax error. |
| 00:42 | <AryehGregor> | Well, you have an even number of plus signs, so conceivably not, but it's certainly not recommended coding style. |
| 00:42 | <othermaciej> | X-Chat feels crufty compared to Colloquy now, though to be fair, lately I have only run it on Windows |
| 00:42 | <othermaciej> | dunno if it feels better in its native habitat |
| 00:43 | <MikeSmith> | because of public wifi in several places in Australia blocking port 6667 when I was traveling there, I recently set up screen+irssi and been pretty happy with that too |
| 00:43 | <sideshow> | yoo hoo |
| 00:43 | <MikeSmith> | that's me |
| 00:44 | <MikeSmith> | I find irssi with the nm.pl and wlstat.pl plugins to be fairly usable |
| 00:45 | <MikeSmith> | nm does proper aligning an coloring of nicks |
| 00:45 | <MikeSmith> | wlstat.pl gives you a human-readable channel list at the bottom of the screen |
| 00:45 | <MikeSmith> | and irssi handles unicode with no problems too |
| 00:46 | <MikeSmith> | anyway, the trend at http://arewefastyet.com/ is very cool |
| 00:46 | <roc> | I hate Colloquy. I have not been able to figure out how to collect alerted messages so I can read them even if they've escaped from scrollback |
| 00:47 | <MikeSmith> | roc: yeah, that's annoying |
| 00:47 | <micheil> | MikeSmith: there's also: http://arewefirstyet.com/ |
| 00:47 | <MikeSmith> | micheil: thanks |
| 00:48 | <MikeSmith> | micheil: what's this measuring? |
| 00:48 | <micheil> | where the search terms for JavaScript rank on google |
| 00:48 | <roc> | it also has crazy bugs where it sometimes stops redrawing |
| 00:48 | <micheil> | as currently if you look for help on JS, the decent documentation is no where to be seen |
| 00:48 | <roc> | and sometimes there are visual artifacts |
| 00:48 | <MikeSmith> | roc: ping NoOneButMe or akempgen on #colloquy |
| 00:49 | <MikeSmith> | I think there's also a bug tracker for Colloquy but can't remember where |
| 00:49 | <roc> | and there's no support for user-configured hyperlinking |
| 00:49 | <roc> | yet |
| 00:49 | <roc> | I still use it |
| 00:49 | <roc> | obviously something is wrong with me |
| 00:50 | <roc> | anyway I'm switching to Windows soon, so it doesn't matter |
| 00:50 | <MikeSmith> | roc: http://colloquy.info?bugs or http://colloquy.info/project/report/1 |
| 00:51 | <MikeSmith> | wow, 536 bugs |
| 00:51 | <MikeSmith> | 536 *active* bugs |
| 00:51 | <MikeSmith> | Colloquy needs some more developers… |
| 00:56 | <MikeSmith> | http://arewefastyet.com/ makes me wonder whether that point on the Sunspider graph around 370ms or whatever is going to be where all the implementations will end up plateauing for a while |
| 00:56 | <othermaciej> | there is a lot of room for improvement in Colloquy |
| 00:56 | <Hixie> | MikeSmith: check out how many active bugs mozilla or webkit have ;-) |
| 00:57 | <MikeSmith> | Hixie: well, yeah |
| 00:57 | <MikeSmith> | would be more fair to compare how many bugs Chatzilla has, maybe |
| 00:58 | <Hixie> | number of open bugs is a function of the size of the QA base, not the engineering base |
| 00:58 | <MikeSmith> | about I meant maybe everybody will plateau (or whatever better word) there due to all having basically reached the same limits as far as what performance can be squeezed using the current techniques (that have come around in the last 2 years or whatever) |
| 00:59 | <othermaciej> | bug in / out rate are more interesting metrics than open bug level IMO |
| 00:59 | <AryehGregor> | Number of open bugs is a function of the size of the bug-reporter base. |
| 00:59 | <MikeSmith> | Hixie: I think in the case of Colloquy, it's the same base |
| 00:59 | <MikeSmith> | :) |
| 01:00 | <roc> | bugzilla.mozilla.org also has bugs for lots of non-Firefox things. Like every time a Mozilla employee requests hardware, that's a bug |
| 01:00 | <roc> | we also have bugs assigned to the legal department |
| 01:00 | <MikeSmith> | I don't know who maintains http://arewefastyet.com/ but it might be worthwhile to add Opera to it |
| 01:00 | <MikeSmith> | Carakan |
| 01:01 | <AryehGregor> | MikeSmith, #3 on http://arewefastyet.com/faq.html |
| 01:01 | <roc> | MikeSmith: dvander⊙mc However, they can't add Carakan easily because no standalone JS shell is available |
| 01:02 | <MikeSmith> | jgraham: ↑ gsnedders |
| 01:03 | <roc> | MikeSmith: I think we'll probably plateau on Sunspider because we don't think it's a great benchmark at this point, so once we've beaten everybody else the incentive to keep going is low |
| 01:03 | <MikeSmith> | AryehGregor: thanks |
| 01:03 | <MikeSmith> | roc: I see |
| 01:03 | <MikeSmith> | I know JS benchmarks are kind of touchy subject anyway |
| 01:04 | <Craig`> | hey guys, is it possible to check if an image is a part of another image? guessing i'd have to use canvas. |
| 01:04 | <Hixie> | from js? |
| 01:04 | <Hixie> | there's no direct api for it |
| 01:04 | <Philip`> | "part of"? |
| 01:04 | <Hixie> | you could as you say implement it manually using canvas to get the image data |
| 01:04 | <MikeSmith> | roc: so maybe I shouldn't have brought it up here… but anyway, it's great to see the progress that chart shows has been made over the last couple months |
| 01:05 | <Craig`> | Philip`, like one image is a piece of another |
| 01:05 | <roc> | touchy? we do touchy here :-) |
| 01:05 | <Craig`> | for example a picture of a human, the sub-image may just be the head, and i want to check if the whole body contains the head image inside |
| 01:05 | <roc> | I'm not sure what is touchy though |
| 01:05 | <Philip`> | Like you have a 10x10 image and a 20x20 image and want to see if any 10x10 region of the larger image is precisely identical to the smaller image? |
| 01:06 | <heycam> | MikeSmith, thanks! |
| 01:06 | <MikeSmith> | roc: I suspect there was probably a measurable difference just do the fact of heycam joining the mozilla team :) that's the kind of voodoo he seems to have |
| 01:06 | <Craig`> | Philip`, yes |
| 01:06 | <heycam> | (and yeah i meant curses based) |
| 01:07 | <roc> | he's stuck in Auckland so hasn't had much chance to influence the rest of Mozilla yet :-) |
| 01:07 | <MikeSmith> | heh |
| 01:07 | <MikeSmith> | lol |
| 01:07 | <MikeSmith> | heycam: you moved already? |
| 01:07 | <MikeSmith> | I really want to visit Auckland |
| 01:07 | <MikeSmith> | you dudes please find me a business reason to travel to Auckland for a visit |
| 01:08 | <heycam> | yeah just arrived a few weeks ago |
| 01:08 | <heycam> | come on over :) |
| 01:09 | <Hixie> | anyone got an animated GIF with frame numbers? a testcase animated gif? |
| 01:11 | heycam | brb lunch |
| 01:14 | <MikeSmith> | Peter`: when I first read "The Chromium Team chose to enable their implementation of the FileSystem API by default. ", it seemed like it implied there was some other WebKit-based implementation of the FileSystem API |
| 01:16 | <MikeSmith> | maybe "The Chromium Team recently implemented the FileSystem API, and has now chosen to enable it by default in Chrome." or something would be better |
| 01:16 | <MikeSmith> | (or maybe it's just me) |
| 01:22 | <MikeSmith> | "There is a downside too, as the advocated API is asynchronous, it has a steep learning curve." |
| 01:22 | <MikeSmith> | in general, do asynchronous APIs have a really steeper learning curve than synchronous ones? |
| 01:23 | <MikeSmith> | I mean, once you get past the initial step of learning how to program that way at all? |
| 01:23 | <MikeSmith> | hmm, I guess they do |
| 01:24 | <Philip`> | [Craig]: Sounds like getImageData and a string search is the best you can do, then |
| 01:24 | <MikeSmith> | or at least, they are necessarily always more complicated a bit at least |
| 01:34 | <AryehGregor> | Mozilla people (roc, sicking): how long should I wait before poking people about checkin-needed not being checked in? And who do I poke? It's been five days. https://bugzilla.mozilla.org/show_bug.cgi?id=586763 |
| 01:36 | <timeless_mbp> | AryehGregor: dao is a good person to poke |
| 01:37 | <timeless_mbp> | or gavin perhaps (not sure if he still does that) |
| 01:37 | <timeless_mbp> | dao landed something for me monday morning |
| 01:37 | <timeless_mbp> | in theory i could do it, but in practice the tree scares me |
| 01:38 | <gavin> | I can check it in tomorrow |
| 01:39 | <AryehGregor> | gavin, thanks. |
| 01:43 | <sicking> | AryehGregor: the best thing to do is ask around in #developers on irc.mozilla.org |
| 01:43 | <sicking> | oh, gavin already answered you |
| 01:47 | <sicking> | AryehGregor: i might give it a try tonight if i don't get home too late |
| 01:49 | <AryehGregor> | Okay, thanks. |
| 03:37 | heycam | wonders why @html5douche tweeted non-doucheily |
| 03:45 | <wirepair> | ha, this is way more amusing than i thought it would be |
| 03:46 | <wirepair> | damn you heycam for ruining my concentration ;) |
| 04:09 | <MikeSmith> | heycam: I think it's because he forgot what account he was tweeting from… |
| 04:10 | <heycam> | MikeSmith, likely! |
| 04:12 | <MikeSmith> | cool to see this: |
| 04:12 | <MikeSmith> | http://dougt.org/wordpress/2010/10/desktop-notifications-in-fennec/ |
| 04:12 | <MikeSmith> | annevk should be happy |
| 04:12 | <MikeSmith> | heycam: did you hear that annevk is a WG chair now? |
| 04:13 | <MikeSmith> | of the Web Notification WG |
| 04:13 | <heycam> | MikeSmith, I did! |
| 04:13 | <heycam> | all grown up |
| 04:13 | <MikeSmith> | heh |
| 04:13 | <heycam> | :) |
| 06:47 | <hsivonen> | Hixie: FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=605373 |
| 06:47 | <hsivonen> | scoping object strikes again :-( |
| 06:48 | <Hixie> | yeah, unfortunately IE's behaviour is basically a non-starter on that one |
| 06:48 | <Hixie> | (they just drop the <object> from the DOM entirely) |
| 06:48 | <Hixie> | we'll always have regressions |
| 06:49 | <Hixie> | or pages that don't parse ideally |
| 06:49 | <Hixie> | since there are pages depending on different contradictory behaviours |
| 06:49 | <Hixie> | at some point we just have to draw a line and accept it |
| 06:49 | <Hixie> | (dunno which side of the line this one is on) |
| 07:16 | <shepazu> | anyone have an opinion on whether it's better to use multiple <aside>s for different bits of a sidebar, such as a blogroll and an archive list, or to use a single <aside> with multiple child <section>s? |
| 07:24 | <Hixie> | shepazu: both are fine |
| 07:25 | <Hixie> | shepazu: really it depends whether stylistically it would be fine for one part to be elsewhere or whether the whole thing should always stick together |
| 07:29 | <shepazu> | Hixie: thanks, I thought that might be the answer... now I have to decide how related the sections are... doing some tweaking of http://www.w3.org/Graphics/SVG/ |
| 07:32 | <shepazu> | might be good to have separate asides, so the different sections could be reordered, put on different sides of the page, etc... anyway, good to know that both are reasonable |
| 07:40 | <Peter`> | MikeSmith: it's mainly the idea of asynchronous programming which is hard for people to understand |
| 08:26 | <jgraham> | Hixie: I'm pretty sure we has at least a couple of sites break due to the <object> thing. I meant to look up the sites but didn't |
| 08:29 | <Hixie> | given the wacked out things IE does with <object> i would expect it to be one of less successful areas |
| 08:40 | <jgraham> | Right, but that doesn't mean that we need to gratuitously break sites if it is avoidable |
| 08:41 | <jgraham> | Since no one else but IE used the IE behaviour and these breakages are regressions |
| 08:43 | <hsivonen> | jgraham: at this point, reading the code of the old WebKit tree builder in order to figure out what exactly it did would be nice |
| 08:44 | <hsivonen> | no progress on https://bugs.webkit.org/show_bug.cgi?id=46936 |
| 08:55 | <hsivonen> | aaaargh. interaction with legacy stuff strikes again: https://bugzilla.mozilla.org/show_bug.cgi?id=604660 |
| 08:59 | <nessy> | amongst some open video software developers we are developing a proposal for HTTP adaptive streaming - mostly focused on Ogg and WebM with some specifications for extending HTML5 APIs - I wonder if it would be appropriate to chuck this into the WHATWG wiki in preparation for discussions on the mailing list? |
| 08:59 | <Hixie> | jgraham: oh i'm not saying we shouldn't fix it if there's a good fix that does more good than harm |
| 08:59 | <Hixie> | jgraham: just that i'm not surprised to see that kind of problem come up |
| 09:06 | <annevk> | nessy, go ahead |
| 09:06 | <nessy> | annevk: cool, ta |
| 09:07 | <annevk> | WHATWG wiki is open for most everything, and definitely everything that is related to web standards |
| 09:38 | <annevk> | ArrayBuffer exposes endianness? |
| 09:38 | <annevk> | oh well |
| 10:12 | <hsivonen> | I wish the script running section of the spec had reminded me that XSLT-inserted scripts need to behave like parser-inserted scripts |
| 10:13 | <jgraham> | Oh man, I hadn't even considered the possibility of xslt inserted scripts |
| 10:19 | <jgraham> | Can you make xslt work with text/html content during parsing? I can't think of an easy way but there could be something I missed |
| 10:20 | <hsivonen> | jgraham: do you mean applying XSLT to text/html during parsing? |
| 10:21 | <jgraham> | Yes |
| 10:21 | <hsivonen> | jgraham: not with anything equivalent to <?xml-stylesheet, no |
| 10:22 | <hsivonen> | jgraham: I have no idea what would happen if you passed a document that's still being parsed to the XSLT JS API |
| 10:22 | <jgraham> | That was more what I was wondering about |
| 10:24 | <hsivonen> | I believe XSLT-created scripts in the JS API case should be prevented from executing like innerHTML-created scripts |
| 10:40 | <hsivonen> | ...or maybe not |
| 10:42 | <hsivonen> | happy happy time ahead with scripts inserted via XSLTProcessor and createContextualFragment |
| 12:33 | <hsivonen> | stuff I've learned today: an XSLT transform fails to compile in Gecko if it doesn't have the version="1.0" attribute |
| 12:42 | <hsivonen> | why does Chrome throw a WRONG_DOCUMENT_ERR when moving a node from an XSLT result doc to an HTML page? |
| 12:43 | <jgraham> | Isn't that a case where DOM Core literalism would make you use adoptNode? |
| 12:44 | <annevk> | hsivonen, WebKit has not yet removed throwing WRONG_DOCUMENT_ERR for certain scenarios |
| 12:44 | <hsivonen> | jgraham: yeah |
| 12:44 | <hsivonen> | annevk: ok |
| 12:45 | <hsivonen> | http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToDocument.html |
| 12:45 | <hsivonen> | Opera runs the script once it's adopted |
| 12:45 | <hsivonen> | Gecko trunk and Chrome don't run it |
| 12:45 | <hsivonen> | yay for interop |
| 12:49 | jgraham | doesn't have any issues with decomplexifying XSLT support if possible |
| 12:50 | <annevk> | hsivonen, what hotel are you staying at for TPAC? |
| 12:50 | <hsivonen> | Hotel de congres |
| 12:51 | <hsivonen> | annevk: the one that a while ago still had the 100% .swf site |
| 12:52 | <annevk> | http://www.hoteldescongres.com/ |
| 12:52 | <annevk> | ? |
| 12:52 | <annevk> | seems there's less Flash now |
| 12:52 | <hsivonen> | annevk: yes and yes |
| 12:53 | <annevk> | number of nights... hmm |
| 12:53 | <annevk> | like I know |
| 12:55 | <hsivonen> | http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToFragment.html |
| 12:55 | <hsivonen> | script runs in Firefox and Opera |
| 12:55 | <hsivonen> | not in WebKit |
| 12:58 | <annevk> | I'm staying there too now |
| 12:58 | <annevk> | thanks |
| 13:12 | <hsivonen> | maybe I should test DOMParser-created scripts next... |
| 13:13 | <hsivonen> | and maybe XHR-created scripts |
| 13:20 | <hsivonen> | annevk: Opera disagrees with Firefox and WebKit on http://hsivonen.iki.fi/test/moz/scripts/xhr.html |
| 13:22 | <hsivonen> | hmm. IE9 can't adopt a node from XHR into a displayed doc |
| 13:22 | <hsivonen> | boo |
| 13:25 | <hsivonen> | Gecko disagrees with WebKit and Opera: http://hsivonen.iki.fi/test/moz/scripts/xhr-importNode.html |
| 14:07 | <karlcow> | The Design of HTML5 - http://adactio.com/articles/1704 |
| 14:07 | <karlcow> | huge blog post |
| 14:09 | <annevk> | it's a transcription |
| 14:11 | <karlcow> | annevk: yep of the conference Fronteers 2010 |
| 14:24 | <MikeSmith> | annevk: in this tweet: http://twitter.com/#!/DennisLaumen/status/27818124542 |
| 14:25 | <MikeSmith> | the "ik kon me geen directe pimp herinneren" part |
| 14:25 | <MikeSmith> | how would you translate that/ |
| 14:25 | <MikeSmith> | "I can't recall a direct pimp"? |
| 14:25 | <MikeSmith> | "I can't recall pimping directly"? |
| 14:26 | <annevk> | I do not remember direct pimping |
| 14:26 | <annevk> | so yeah, something like that |
| 14:26 | <MikeSmith> | ok |
| 14:26 | <MikeSmith> | thanks |
| 14:41 | <hsivonen> | annevk: I recall someone (you?) tweeting from fronteers that authors weren't aware that vendor-prefixed CSS properties can be discontinued at any time |
| 14:41 | <hsivonen> | annevk: do I recall correctly? are authors really thinking that the vendor-prefixed stuff is stable? |
| 14:42 | <jgraham> | I thought they were unaware that it was "invalid" |
| 14:42 | <jgraham> | s/"/*/ |
| 14:43 | <hsivonen> | oh |
| 14:49 | <annevk> | some think it is valid |
| 14:49 | <annevk> | I am not sure whether they think it is stable |
| 14:53 | <hsivonen> | annevk: ok. thanks |
| 14:53 | <hsivonen> | does IE9 use the new JS engine for the old document modes? |
| 14:53 | <hsivonen> | and the new Direct2D graphics layer? |
| 14:55 | <hsivonen> | Opera disagrees with Gecko, WebKit and IE9 beta 1 on http://hsivonen.iki.fi/test/moz/scripts/DOMParser.html |
| 15:02 | <hsivonen> | the weirdest thing I've learned today: |
| 15:02 | <hsivonen> | http://hsivonen.iki.fi/test/moz/scripts/innerHTML-in-doc-defer-plus-cruft.html |
| 15:02 | <hsivonen> | innerHTML script runs in IE |
| 15:02 | <hsivonen> | http://hsivonen.iki.fi/test/moz/scripts/innerHTML-in-doc-defer.html |
| 15:02 | <hsivonen> | innerHTML script doesn't run in IE |
| 15:03 | <hsivonen> | MSDN said defer would run |
| 15:03 | <hsivonen> | first I figured that MSDN was wrong |
| 15:03 | <hsivonen> | then I learned you need to have something in addition to the script element in the innerHTML setter argument for the script to run |
| 15:09 | <MikeSmith> | hsivonen: during my recent language messings-around in twitter, I was kind of a surprised to realize there doesn't seem to be any direct article or indirect article in Finnish |
| 15:09 | <MikeSmith> | is that the case? |
| 15:09 | <annevk> | oh |
| 15:09 | <annevk> | are we gonna publish today? |
| 15:09 | <annevk> | do I need to do anything? |
| 15:09 | <MikeSmith> | yeah |
| 15:09 | <MikeSmith> | change date to Oct 19 |
| 15:09 | <annevk> | I guess I haven't merged recent changes |
| 15:09 | <MikeSmith> | please do now :) |
| 15:10 | <hsivonen> | MikeSmith: do you mean like "the" or "a"/"an"? |
| 15:10 | <MikeSmith> | yeah |
| 15:10 | <MikeSmith> | hsivonen: ↑ |
| 15:10 | <annevk> | I guess I have some more time |
| 15:10 | <hsivonen> | MikeSmith: there is none |
| 15:10 | <hsivonen> | (aren't those definite and indefinite, not direct and indirect?) |
| 15:10 | <MikeSmith> | hsivonen: oops, yeah |
| 15:11 | <MikeSmith> | I means definite/indefinite |
| 15:11 | <MikeSmith> | annevk: please do get it done as soon as you can |
| 15:11 | <annevk> | can you give me 45min? |
| 15:11 | <hsivonen> | articles are kinda useless, so we don't have those |
| 15:11 | <MikeSmith> | annevk: yeah, sure |
| 15:12 | <hsivonen> | definite vs. indefinite information is baked into the case in some cases |
| 15:12 | <hsivonen> | oops. pun unintended |
| 15:12 | <MikeSmith> | hsivonen: yeah, Japanese and most asian languages don't have them either |
| 15:12 | <MikeSmith> | heh |
| 15:13 | <MikeSmith> | hsivonen: but Japanese speakers and other Asian non-native English learners seem to have a lot of trouble using "a" and "the" correctly in English |
| 15:13 | <MikeSmith> | it's pretty hard |
| 15:13 | <hsivonen> | I don't find it conceptually that hard |
| 15:13 | <MikeSmith> | but it seems like FInnish speakers don't have that problem nearly as much |
| 15:14 | <MikeSmith> | I think there are some instances where it's hard |
| 15:14 | <MikeSmith> | though I can't think of particulars right now |
| 15:14 | <MikeSmith> | I know there are some where I had a difficult time explaining why "a" is needed instead of "the" |
| 15:14 | <MikeSmith> | or vice versa |
| 15:16 | <MikeSmith> | hsivonen: also, Google Translate Finnish<->English seems to be relatively poor quality |
| 15:17 | <hsivonen> | MikeSmith: yeah. I use source language to English when I use Google Translate |
| 15:17 | <hsivonen> | (and Google would use English as an intermediate language anyway) |
| 15:17 | <MikeSmith> | machine translation of Japanese->English is also poor quality |
| 15:18 | <MikeSmith> | the reason for it isn't because of Google Translate in particular |
| 15:18 | <MikeSmith> | it's just very difficult to do decent Japanese->English machine translation |
| 15:18 | <hsivonen> | human translation quality from English to Finnish varies rather strikingly |
| 15:18 | <MikeSmith> | interesting |
| 15:19 | <MikeSmith> | is there a lot that needs to be inferred when doing it? |
| 15:19 | <hsivonen> | there are some books (typically non-fiction) where one can tell what the English expressions were |
| 15:19 | <MikeSmith> | ah |
| 15:19 | <hsivonen> | that is, the result is Finnish, but no one would write Finnish like that from scratch |
| 15:19 | <MikeSmith> | I see |
| 15:20 | <MikeSmith> | I was thinking more of the other way around |
| 15:20 | <MikeSmith> | from Finnish to English |
| 15:20 | <MikeSmith> | in comparison, one big problem with translating Japanese to English is that the subject can be omitted from a sentences |
| 15:20 | <MikeSmith> | *from sentences |
| 15:21 | <MikeSmith> | that is, the sentences in the Japanese source may lack subjects |
| 15:21 | <hsivonen> | and the translator has to make a guess? |
| 15:21 | <MikeSmith> | the only way to know what the subject is is to read the previous sentence or parargraph |
| 15:21 | <MikeSmith> | human translator does not need to guess |
| 15:21 | <hsivonen> | ah |
| 15:21 | <MikeSmith> | it's almost always unambiguous to humans |
| 15:22 | <MikeSmith> | but harder to teach a machine |
| 15:22 | <MikeSmith> | though not impossible of course |
| 15:22 | <MikeSmith> | anyway, I was speculating that there might be some similar reasons why going from Finnish to English with machine translation might be more difficult than most |
| 15:23 | <MikeSmith> | I mean, I've been surprised to find that Google Translate does a decent job with some languages that I had naively assumed it might have a lot of difficulty with |
| 15:23 | <MikeSmith> | Hebrew, for example |
| 15:23 | <MikeSmith> | and Arabic |
| 15:23 | <MikeSmith> | and Hindi |
| 15:24 | <MikeSmith> | it consistently seems to do better with all those than it does with Finnish |
| 15:24 | <hsivonen> | I think the top two things that require inference when translating from Finnish to English are using the future tense and guessing he vs. she |
| 15:24 | <MikeSmith> | OK |
| 15:26 | <hsivonen> | I mean for a machine. For a human, the future vs. present information is there but not in the verbs |
| 15:30 | <MikeSmith> | hsivonen: I see |
| 15:30 | <hsivonen> | hmm. So now the spec has a "Noah ark clause" in addition to the "adoption agency algorithm" |
| 15:30 | <hsivonen> | *Noah's |
| 15:31 | <MikeSmith> | yeah, interesting choice of name there |
| 15:37 | <annevk> | there's a restaurant here in Oslo called Noah's Ark |
| 15:37 | <annevk> | they've got nice burgers |
| 15:37 | <hsivonen> | annevk: do they come in pairs? |
| 15:38 | <annevk> | unfortunately not :) |
| 15:40 | <annevk> | so only <video> has an audio attribute |
| 15:40 | <annevk> | not <audio> |
| 15:40 | <annevk> | hmm |
| 15:43 | <annevk> | MikeSmith, http://dev.w3.org/html5/html4-differences/ has been updated |
| 15:43 | <annevk> | fwiw, http://www.w3.org/TR/progress-events/ has been updated too |
| 15:46 | <MikeSmith> | annevk: thanks |
| 15:46 | <MikeSmith> | annevk: btw, you saw that Doug Turner had implemented support for the Web Notifications spec in Fennec? |
| 15:46 | <MikeSmith> | I don't recall if he mentioned it on the list |
| 15:47 | <annevk> | I read a post last Friday I believe |
| 15:47 | <MikeSmith> | yeah |
| 15:47 | <annevk> | and I saw you mentioning it again somewhere in the logs :) |
| 15:47 | <MikeSmith> | heh |
| 15:47 | <MikeSmith> | OK |
| 15:50 | <karlcow> | I wonder if Japanese <-> Finish works well? |
| 15:52 | <karlcow> | when I see romaji and finish's spelling, I sometimes wonder if there are not the same language. It is very strange. |
| 15:53 | <hsivonen> | karlcow: I expect the market isn't big enough for anyone to bother |
| 15:53 | <karlcow> | hsivonen: you mean for the translation engine? |
| 15:53 | <hsivonen> | karlcow: right |
| 15:54 | <hsivonen> | (Google translates Japanese to English to Finnish when asking it to translate from Japanese to Finnish) |
| 15:55 | <karlcow> | For the market, for sure. :) But I was more interested by the work of art :) |
| 15:55 | <MikeSmith> | hsivonen: what's the current conclusion about which language family (families) Finnish belongs to? |
| 15:55 | <MikeSmith> | for comparison, I think there is currently not actually a real consensus on where Japanese developed from |
| 15:55 | <karlcow> | http://educationjapan.org/jguide/origins.html |
| 15:56 | <hsivonen> | MikeSmith: I believe the English name is Fenno-Ugric |
| 15:56 | <MikeSmith> | OK |
| 15:56 | <karlcow> | Japanese is often regarded as a possible member of the Altaic group, but the relationship is generally considered tentative or unproven. |
| 15:56 | hsivonen | has to go |
| 15:56 | <karlcow> | "Altaic includes three main subfamilies (Turkic, Mongolian and Manchu-Tungus), while Uralic includes the Finn-Ugric languages (Hungarian, Finnish, Estonian, etc.) and the Samoyedic tongues (spoken in parts of Russia). " |
| 15:57 | <MikeSmith> | karlcow: my understanding is that it's beens a long time since any serious researchers actually still classified Japanese in the Altaic group |
| 15:57 | <MikeSmith> | but I could be wrong |
| 15:58 | <karlcow> | MikeSmith: I'm not qualified at all. Just reading what I find. :) |
| 15:59 | <karlcow> | "Vowel harmony is common in Altaic and Uralic languages, such as Turkish and Finnish, and later I will show how it has been used to support theories relating Japanese to these groups." -- http://linguistics.byu.edu/classes/ling450ch/reports/japanese.htm |
| 15:59 | <karlcow> | "Japanese is not conclusively linked to any other language or family of languages. It has remained a mystery despite all these centuries of research, and continues to prod the people who speak it to seek out their identity." |
| 16:00 | <MikeSmith> | karlcow: I think it is becoming less of a mystery recently |
| 16:00 | <MikeSmith> | research seems to be leaning towards this: |
| 16:00 | <MikeSmith> | http://en.wikipedia.org/wiki/Goguryeo_language |
| 16:00 | karlcow | is reading |
| 16:01 | karlcow | wants a time machine. |
| 16:01 | <karlcow> | and poneys |
| 16:04 | <karlcow> | ooooh and for the catastrophists, end of the world theorists or just poets ;) there is a big giant ass ring on the sun :) |
| 16:05 | <MikeSmith> | so from reading http://en.wikipedia.org/wiki/Finno-Ugric_languages I see that Hungarian and Estonian are among the languages that Finnish is related to |
| 16:06 | <karlcow> | http://www.nasa.gov/topics/solarsystem/sunearthsystem/main/News101610-3flares.html |
| 16:07 | <karlcow> | MikeSmith: migration of people? waves of invasion? viral language? :) |
| 16:08 | <Workshiva> | Terrible how much information has been lost |
| 16:09 | <karlcow> | the ring is more visible on this image http://spacefellowship.com/wp-content/uploads/2010/10/489332main_euvfilament-20101016.jpg |
| 16:10 | <MikeSmith> | karlcow: cool |
| 16:10 | <MikeSmith> | Workshiva: about language history? |
| 16:16 | <Workshiva> | MikeSmith: History in general |
| 16:19 | <MikeSmith> | some history can at least be reconstructed from tangible artifacts |
| 16:20 | <MikeSmith> | but for extinct languages that without a written record, the info really is lost forever |
| 16:21 | <MikeSmith> | I mean, there is always the possibility of archaeologists uncovering artifacts that we can recover history from about a lot of things |
| 16:21 | <MikeSmith> | but not about spoken language |
| 16:21 | <MikeSmith> | unrecorded spoken language |
| 16:29 | <Workshiva> | But even written history is very sparse compared to the total of reality |
| 16:43 | <MikeSmith> | I have noticed lately that Chrome on OSX seems to be doing caching more aggressively than other browsers |
| 16:43 | <MikeSmith> | or maybe it's just me |
| 16:45 | <MikeSmith> | remote resources but also caching file:// resources and not loading them from disk after I've made changes to them, but instead keeping right on serving them from cache |
| 16:46 | <MikeSmith> | seems like file:// resources should arguably never get cached to begin with |
| 16:51 | <MikeSmith> | I wish there were a replacement word in English for "now" |
| 16:51 | <MikeSmith> | so that I don't mistakenly type "not" when I meant to type "now" |
| 16:52 | <Philip`> | MikeSmith: "presently"? |
| 16:52 | <karlcow> | too long? |
| 16:53 | <MikeSmith> | yeah |
| 16:53 | <MikeSmith> | Philip`: e.g., "http://www.w3.org/TR/2010/WD-html5-diff-20101019/ is not ready for publication" |
| 16:53 | <MikeSmith> | http://www.w3.org/TR/2010/WD-html5-diff-20101019/ is presently ready for publication |
| 16:54 | <karlcow> | MikeSmith: you can type "ima" and have an automatic script to translate but that will severely damage your brain and you end by saying "ima" orally to English speakers :) |
| 16:54 | <jgraham> | Why not just say "is ready for publication" |
| 16:54 | <MikeSmith> | and yeah, I know I could omit "now" and it would still make sense |
| 16:54 | <MikeSmith> | jgraham: I knew you would say that |
| 16:54 | <jgraham> | Me? |
| 16:54 | <karlcow> | :D |
| 16:54 | <jgraham> | Philip` was far more likely |
| 16:54 | <MikeSmith> | why not, is because for whatever reason, I typed "http://www.w3.org/TR/2010/WD-html5-diff-20101019/ is not ready for publication" initially |
| 16:55 | <MikeSmith> | I didn't spend a whole lot of time thinking about why I wanted the "now" in there to begin with |
| 16:55 | <MikeSmith> | I just typed it |
| 16:55 | <MikeSmith> | mistyped it |
| 16:55 | <MikeSmith> | jgraham: well, not you in particular |
| 16:55 | <karlcow> | or a script which does "uri pub" and creates the sentence automatically :p |
| 16:55 | <MikeSmith> | "you" in general |
| 16:56 | <karlcow> | "at the moment, at present, at the present (time/moment), at this moment in time, currently, presently." |
| 16:56 | <karlcow> | "3 you must leave now: at once, straightaway, right away, right now, this minute, this instant, immediately, instantly, directly, without further ado, promptly, without delay, as soon as possible; informal pronto, straight off, ASAP." |
| 16:56 | <MikeSmith> | thanks Mr. Encyclopedia |
| 16:57 | <MikeSmith> | ;) |
| 16:57 | <karlcow> | "http://www.w3.org/TR/2010/WD-html5-diff-20101019/ is without further ado ready for publication" |
| 16:57 | <karlcow> | hmmm |
| 16:57 | <MikeSmith> | heh |
| 16:57 | <karlcow> | coming from Apple Dictionary |
| 16:57 | <MikeSmith> | "now" in Hungarian is "most" |
| 16:57 | <karlcow> | The thesaurus section |
| 16:58 | <jgraham> | s/without further ado/after much ado/ |
| 16:58 | <jgraham> | and you can set yourself up for a world of Shakespeare puns |
| 16:59 | karlcow | is trying to guess the difference between the two jgraham gave. |
| 16:59 | <karlcow> | reaching my English inabilities |
| 16:59 | <MikeSmith> | I like "nå" |
| 17:00 | <jgraham> | karlcow: Just that "Much ado about nothing" is the play |
| 17:00 | <jgraham> | (so "much ado" for short) |
| 17:01 | <karlcow> | aaaah. capice |
| 17:01 | <karlcow> | merci |
| 17:01 | <jcranmer> | lol |
| 17:01 | <jcranmer> | Come back later! Enjoy your fall break~ |
| 17:01 | <jcranmer> | Brandon |
| 17:01 | <jcranmer> | no |
| 17:01 | <jcranmer> | Chandler |
| 17:01 | <jgraham> | I thought "capice" was Italian |
| 17:01 | <MikeSmith> | I think I will just start using "ahora" |
| 17:02 | <MikeSmith> | with ital |
| 17:02 | <MikeSmith> | "http://www.w3.org/TR/2010/WD-html5-diff-20101019/ is ready for publication _ahora_" |
| 17:03 | <MikeSmith> | I think more European speakers already know what "ahora" means, right? |
| 17:03 | Philip` | wouldn't know that |
| 17:04 | <MikeSmith> | really? |
| 17:04 | <MikeSmith> | hmm |
| 17:05 | <karlcow> | but agora is easier to pronunce |
| 17:05 | <MikeSmith> | "now" in "nu" in Esparanto |
| 17:05 | <karlcow> | though agora might confuse greek people |
| 17:05 | <MikeSmith> | and in several other languages of course |
| 17:06 | <MikeSmith> | but I don't think most native English speakers know "nu" |
| 17:06 | <MikeSmith> | I wonder why Google Translate doesn't do Esparanto |
| 17:07 | <MikeSmith> | seems like it used to |
| 17:09 | <jgraham> | Hmm, I just noticed that the phrasing of the HTML5 spec around foreign content stuff makes it hard to implement in html5lib without invasive changes :( |
| 17:10 | <jgraham> | Specifically the "except that if those rules say to reprocess the token, these steps must be finished first" |
| 17:10 | <MikeSmith> | jgraham: was the text added recently? |
| 17:10 | <jgraham> | Yeah |
| 17:10 | <MikeSmith> | I see |
| 17:10 | <MikeSmith> | didn't remember that being in there before |
| 17:11 | <jgraham> | Typically the token is reprocessed by a direct call rather than by spinning the loop again with the same token |
| 17:11 | <MikeSmith> | I suspect other implementations might be doing it that same way |
| 17:11 | <jgraham> | I think it is OK for Henri as phrased |
| 17:11 | <jgraham> | I dunno about the WebKit implementation |
| 17:12 | <MikeSmith> | I wonder about the PHP parser |
| 17:12 | <jgraham> | Ask gsnedders |
| 17:12 | MikeSmith | tries to remember what others there are at this point |
| 17:12 | <MikeSmith> | there is a DOM parser in node.js now |
| 17:12 | <MikeSmith> | but it does not attempt to conform to the HTML5 spec yet |
| 17:13 | <MikeSmith> | as far as I remember |
| 17:13 | <MikeSmith> | I think there are actually more than one DOM implementations in node |
| 17:13 | <MikeSmith> | that are in various states of development |
| 17:13 | <MikeSmith> | but I think the most mature one is not HTML5-conformant |
| 17:13 | <MikeSmith> | I think hober has been following the work on that one |
| 17:13 | <MikeSmith> | and filed a bug |
| 17:13 | <MikeSmith> | or enhancement request |
| 17:14 | <MikeSmith> | that is should conform to HTML5 |
| 17:14 | <jgraham> | Writing a from scratch HTML5 parser and not following the HTML5 spec is just lame |
| 17:14 | <jgraham> | Well naive |
| 17:14 | <jgraham> | probably |
| 17:14 | <MikeSmith> | well, people don't know |
| 17:14 | <MikeSmith> | they work on a lot of stuff |
| 17:14 | <MikeSmith> | they don't follow every single thing that goes on in standards land |
| 17:15 | <jgraham> | Indeed |
| 17:15 | <MikeSmith> | anyway, I think hober is on top of it |
| 17:15 | <MikeSmith> | in this case |
| 17:15 | <jgraham> | But you might have thought that if you were going to write a HTML parser you would at least check out the HTML spec |
| 17:15 | <jgraham> | hober++ |
| 17:16 | <gsnedders> | MikeSmith: Will be fine for the PHP impl, as that just spins the loop again for it ordinarily |
| 17:16 | <jgraham> | (I know history might have taught you to regard the HTML spec as basically useless for all purposes except inciting markup purity holy wars) |
| 17:16 | <MikeSmith> | gsnedders: k |
| 17:17 | <gsnedders> | MikeSmith: Not that anyone is intending on maintaining it |
| 17:17 | <MikeSmith> | heh |
| 17:17 | <gsnedders> | (I refuse to implement all of the script tokenizer states again.) |
| 17:17 | <MikeSmith> | about the node DOM thing, for now, I'm just glad at all to have a DOM implementation at node |
| 17:17 | <jgraham> | I guess at some point I will end up making a reprocessToken() function or something |
| 17:17 | <MikeSmith> | *in node |
| 17:18 | <jgraham> | and tediously removing all the explicit calls |
| 17:18 | <jgraham> | and then missing some and creating bugs |
| 17:18 | <MikeSmith> | or in JS, really (which is what it comes down to) |
| 17:18 | <jgraham> | and then finding out that there is some special case where it doesn't quite work |
| 17:18 | <MikeSmith> | (I don't know how tightly bound if at all the parser might be to node) |
| 17:19 | <jgraham> | Eventually we will be able to write a whole browser in js |
| 17:19 | <MikeSmith> | heh |
| 17:19 | <jgraham> | and you will run a browser in your browser |
| 17:19 | <MikeSmith> | we certainly may be able to write a validator at least |
| 17:19 | <MikeSmith> | or more specifically, an HTML5 conformance checker |
| 17:19 | <jgraham> | Well the Mozilla people have javascript in js |
| 17:20 | <Philip`> | I thought there was someone on the WHATWG list seriously proposing that the web platform should be extended so that it's complete enough to write a browser |
| 17:20 | <MikeSmith> | yeah |
| 17:20 | <jgraham> | and doing image decoding and stuff can't be that hard |
| 17:20 | <jgraham> | Just need a layout engine |
| 17:21 | <Philip`> | Surely implementing CSS 2.1 can't be that hard |
| 17:21 | <Philip`> | It's just a load of boxes |
| 17:21 | <MikeSmith> | heh |
| 18:07 | <karlcow> | looking at Server Sent Events, and remember Pointcast http://www.nczonline.net/blog/2010/10/19/introduction-to-server-sent-events/ http://en.wikipedia.org/wiki/Push_technology |
| 19:40 | TabAtkin1_ | wishes Server-Sent Events would work in Chrome, or at least he could figure out why his trivial demo isn't working in Chrome. |
| 20:38 | <MikeSmith> | does HTML4 or any other spec say that ID values should be compared case-insensitively? |
| 20:40 | <MikeSmith> | http://validator.w3.org/check?uri=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fmultipage%2Fnamed-character-references.html&charset=%28detect+automatically%29&doctype=HTML+4.01+Strict&group=1&user-agent=W3C_Validator%2F1.1 |
| 20:40 | <MikeSmith> | see the "ID X already defined" errors |
| 20:41 | <MikeSmith> | I am wondering if the W3C validator is intentionally configured to check IDs case-insensitively for some reason |
| 21:07 | <zcorpan> | MikeSmith: ID validation in html4 inherits the sgml rules for IDs (since IDness is specified in the DTD) |
| 21:07 | <MikeSmith> | OK |
| 21:08 | <MikeSmith> | so next question is, did SGML have the notion of case-insensitve IDs |
| 21:25 | <m0> | Hixie: Sorry for the long response :-) It is a Haptics device, my personal experiment is to make Accessibility better for disabled people (blindness) |
| 21:25 | <m0> | s/long/late |
| 21:42 | <Hixie> | hsivonen: i can't say i ever think about xslt, sorry. If you want anything added for it, file a bug, happy to add a note. |
| 21:49 | <david_carlisle> | MikeSmith: yes |
| 21:50 | <MikeSmith> | david_carlisle: IDs in SGML are case-insenstive, you mean? |
| 21:51 | <david_carlisle> | by default yes |
| 21:51 | <david_carlisle> | <y id="aa">xx</y> |
| 21:51 | <david_carlisle> | <y ref="AA">xx</y> |
| 21:51 | <david_carlisle> | validates |
| 21:51 | <david_carlisle> | basically the rules for id are same as rules for element names |
| 21:56 | <zcorpan> | david_carlisle: does the html4 sgml decl make IDs case-insensitive? |
| 21:56 | <david_carlisle> | just looking... |
| 21:57 | <david_carlisle> | I was quicker at reading this stuff in a previous life |
| 21:58 | <david_carlisle> | NAMECASE GENERAL YES |
| 21:58 | <david_carlisle> | ENTITY NO |
| 21:58 | <david_carlisle> | so I think entities are case sensitive everything else not, but I'll just check with onsgmls on an example... |
| 22:00 | <zcorpan> | for some reason i thought IDs were always case-sensitive in sgml |
| 22:09 | <david_carlisle> | zcopan: onsgmls says this is valid |
| 22:09 | <david_carlisle> | $ onsgmls.exe table.html > /dev/null |
| 22:09 | <david_carlisle> | <!DOCTYPE html SYSTEM "HTML4.dtd"> |
| 22:09 | <david_carlisle> | <html> |
| 22:09 | <david_carlisle> | <head> |
| 22:09 | <david_carlisle> | <title>?</title> |
| 22:09 | <david_carlisle> | </head> |
| 22:09 | <david_carlisle> | <body> |
| 22:09 | <david_carlisle> | <table id="aa"> |
| 22:09 | <david_carlisle> | <tr> |
| 22:09 | <david_carlisle> | <td headers="AA"></td> |
| 22:09 | <david_carlisle> | </tr> |
| 22:09 | <david_carlisle> | </table> |
| 22:09 | <david_carlisle> | </body> |
| 22:09 | <david_carlisle> | </html> |
| 22:10 | <zcorpan> | ok |
| 22:10 | <david_carlisle> | sgml spec is as clear as mud, but I'd trust James clark :-) |
| 22:15 | <Hixie> | anyone know why opera doesn't handle http://www.hixie.ch/tests/adhoc/html/navigation/interrupts/harness.html correctly? |
| 22:16 | <Hixie> | it seems to just not be running scripts |
| 22:16 | <Hixie> | oh nm |
| 22:16 | <Hixie> | now it works |
| 22:35 | <heycam> | hsivonen, yt? |
| 22:37 | <zcorpan> | heycam: btw, it would be great if webidl said what to do with too few arguments to constructors and methods (i think it has a note about this) |
| 22:38 | <heycam> | zcorpan, yeah it would be good if there were a note in there saying simply what the requirements are. (it is in fact defined, as a result of the overload resolution stuff.) |
| 22:38 | <heycam> | but i'm not sure people are happy with that overload stuff, so it's probable that that will change |
| 22:39 | <zcorpan> | oh, i didn't know it was defined |
| 22:39 | <heycam> | there's a note in the spec about deciding whether the requirement for too few/many arguments should be changed |
| 22:39 | <heycam> | i believe it currently requires a TypeError for any mismatch of argument count |
| 22:39 | <zcorpan> | ah |
| 22:39 | <heycam> | that i only believe it and not know it is not a great reflection on the writing there :) |
| 22:40 | <zcorpan> | no one throws for too many arguments, i wonder if web content relies on that |
| 22:40 | <heycam> | hope not, then :) |
| 22:41 | <heycam> | if it doesn't, then it might be good for future compat if we want to add more arguments to methods |
| 22:41 | <heycam> | to throw, that is |
| 22:42 | <zcorpan> | yes |
| 22:42 | <zcorpan> | i wonder if webkit and ie are willing to change for the too few arguments case |
| 22:43 | <heycam> | do you know if they allow any invocations for two-few args? or just few a selection of methods (like addEventListener assuming false at the end)? |
| 22:44 | <heycam> | if it's just a few, and they're unwilling to change, we could introduce some overloading to handle those cases |
| 22:44 | <zcorpan> | they allow missing arguments everywhere |
| 22:44 | <heycam> | mm |
| 22:44 | <heycam> | i wonder if it is as important to throw for such cases |
| 22:45 | <gsnedders> | What do they default to for stuff? |
| 22:45 | <heycam> | if we wanted to introduce overloadings with fewer arguments later on... |
| 22:45 | <zcorpan> | gsnedders: undefined |
| 22:45 | <gsnedders> | zcorpan: And then maybe throw if undefined isn't an allowed type for that argument? |
| 22:45 | <gsnedders> | (e.g., undefined can't really become HTMLElement) |
| 22:46 | <heycam> | although undefined can become null which sometimes might be allowed as an HTMLElement arg |
| 22:46 | <zcorpan> | gsnedders: yeah, i guess |
| 22:46 | <heycam> | i like anne's suggestion of removing "null" from the set of object reference values |
| 22:46 | <heycam> | and only explicitly allowing it with a "?" |
| 22:47 | <gsnedders> | heycam: Yeah, it makes sense for it to become another non-object primitive |
| 22:49 | <zcorpan> | in ie document.createElement() is equivalent to document.createElement(null) but different to document.createElement(undefined) |
| 22:49 | <heycam> | :/ |
| 22:49 | <gsnedders> | zcorpan: so creates an element called "null"? |
| 22:51 | <zcorpan> | gsnedders: yes |
| 22:51 | <zcorpan> | getElementById also defaults to null |
| 22:51 | <zcorpan> | so maybe ie defaults to null everywhere |
| 22:51 | <zcorpan> | instead of undefined |
| 22:51 | <zcorpan> | this is ie9 beta |
| 22:51 | <jgraham> | The logical-from-js behaviour would be foo() === foo(undefined) |
| 22:52 | <jgraham> | I think we should throw for too-few arguments but not too many |
| 22:52 | <heycam> | i wonder if sites rely on elements with ID or name "null" |
| 22:52 | <heycam> | jgraham, for consistency with the functions defined in the ES spec? |
| 22:52 | gsnedders | places bet they do |
| 22:52 | <gsnedders> | I think we should throw for both. |
| 22:52 | <jgraham> | heycam: For sanity, mainly |
| 22:53 | <heycam> | you'll have to define sanity :) |
| 22:53 | <zcorpan> | opera and firefox throw for too few but not too many |
| 22:53 | <gsnedders> | It means we can add new features with new arguments, and it's obvious when they aren't supported |
| 22:53 | <heycam> | gsnedders, yeah i think that would be the main argument for throwing for too many |
| 22:53 | <jgraham> | We can't really do that reliably at the moment if others don't throw |
| 22:54 | <jgraham> | And it seems like DOM should be as consistent with javascript as possible |
| 22:54 | <heycam> | if others don't throw, then introducing new overloads with more arguments is already going to be fraught with compat worries then, i suppose! |
| 22:55 | <jgraham> | We should tie it to ES5 strict mode! |
| 22:55 | <jgraham> | (note: not a serious suggestion) |
| 22:55 | <gsnedders> | No, to Harmony! |
| 22:55 | <jgraham> | (although I can imagine people seriously advocating it) |
| 22:55 | <gsnedders> | (note: an even less serious suggestion) |
| 22:56 | <heycam> | i'll tie you to E5 strict mode in a minute! |
| 22:56 | <heycam> | ES5* |
| 22:56 | <Rik`> | so Chrome 7 is the first browser to ship a HTML5 parser, right? |
| 22:56 | <zcorpan> | chrome 7 shipped? |
| 22:56 | <gsnedders> | Well, they haven't shipped it in stable, and Chrome 6 is still beta, no? |
| 22:56 | <gsnedders> | Firefox 4 has shipped in betas, at least |
| 22:57 | <Rik`> | zcorpan: http://googlechromereleases.blogspot.com/2010/10/stable-channel-update.html |
| 22:57 | gsnedders | realizes how out of date he is |
| 22:57 | <aho> | dev channel is at 8.0.552.5 right now :> |
| 22:58 | gsnedders | wonders why TabAtkins_ did the CSS 2.1 IR with 6 (so not even the beta, as agreed before…) |
| 22:58 | <zcorpan> | well then i guess the answer is "yes" |
| 22:59 | <gsnedders> | (Also: sing-along A Wizard of Oz! :D) |
| 23:01 | <heycam> | hsivonen (and anyone else): consider http://mcc.id.au/temp/ser.html and how the xlink:href attribute gets (un-round-tripably) serialised to an attribte named "href" in firefox nightlies (at least) |
| 23:01 | <gsnedders> | (But maybe only I find that awesome.) |
| 23:01 | <heycam> | is that per spec, and if so, is it reasonable behaviour? |
| 23:02 | <gsnedders> | heycam: Off the top of my head, per spec |
| 23:02 | <heycam> | gsnedders, ok. reasonable? |
| 23:02 | <gsnedders> | Yeah, per spec. |
| 23:02 | <gsnedders> | IMO no. |
| 23:02 | <heycam> | imo valid html syntax should be roundtrippable always |
| 23:05 | <zcorpan> | "For each attribute that the element has, append a U+0020 SPACE character, the attribute's name (which, for attributes set by the HTML parser or by Element.setAttributeNode() or Element.setAttribute(), will be lowercase), a U+003D EQUALS SIGN character (=), a U+0022 QUOTATION MARK character ("), the attribute's value, escaped as described below in attribute mode, and a second U+0022 QUOTATION MARK character (")." |
| 23:05 | <hober> | heycam: I see the same in chrome, fwiw |
| 23:05 | <zcorpan> | i think "the attribute's name" is the qualified name |
| 23:05 | <gsnedders> | Why? |
| 23:06 | <jgraham> | why what? |
| 23:07 | <gsnedders> | Why do you think it's the qname? |
| 23:07 | <zcorpan> | because i remember discussing this exact issue a few years back |
| 23:07 | <zcorpan> | and attr.name returns the qname |
| 23:08 | <jgraham> | Could be clearer in the spec |
| 23:08 | <heycam> | looking at http://www.whatwg.org/specs/web-apps/current-work/#adjust-foreign-attributes it doesn't explicitly say what the dom 1 name of the attribute node should be |
| 23:09 | <zcorpan> | heycam: web dom core fixes that :) |
| 23:09 | <zcorpan> | jgraham: yes. i'll file a bug |
| 23:11 | <heycam> | zcorpan, so it does :) |
| 23:12 | <heycam> | but does "attribute name" in html5 mean attr.name? |
| 23:13 | <jgraham> | heycam: Who knows :) Hence the bug |
| 23:13 | <jgraham> | (I assume zcorpan is right that it does) |
| 23:13 | <jgraham> | (but nevertheless that cannot be reliably deduced from the spec) |
| 23:14 | gsnedders | assumed localname, but oh well |
| 23:17 | <jgraham> | So did I but zcorpan made more sense |
| 23:17 | <gsnedders> | zcorpan often does. |
| 23:19 | <heycam> | i did a `host` on the ip address zcorpan filed the bug from to find ...cust.bredbandsbolaget.se. to me it read like "bread and beaujolais", and now i'm hungry. |
| 23:20 | <zcorpan> | lol |
| 23:20 | <zcorpan> | time for sleep |
| 23:20 | <heycam> | later |
| 23:20 | <zcorpan> | bye |
