| 00:05 | <heycam> | mpilgrim, ok, looks like throwing on too few arguments and ignoring extra arguments is the way to go, then |
| 00:06 | heycam | wonders if there's a bot in here that you can use to leave messages for people |
| 00:08 | <Philip`> | heycam: None that I've ever seen, though you can just write your message and hope the recipient reads the IRC logs assiduously |
| 00:11 | <zewt> | any decent irc client highlights messages addressed to you |
| 00:12 | <heycam> | most don't do so if you weren't in the channel at the time someone wishes to leave you a message, though :) |
| 00:12 | <zewt> | so don't not be in the channel :P |
| 00:13 | <heycam> | heh |
| 00:14 | <nimbu> | heycam: http://freenode.net/faq.shtml#memoserv |
| 00:14 | <heycam> | nimbu, oh, interesting, I'll try it |
| 00:17 | <roc> | oh no, that's four people in #whatwg on a Saturday morning |
| 00:27 | <Dashiva> | Is there really a thread going "longdesc does not have backwards compatibility because many platforms and tools don't support it at all" "but it WILL HAVE backwards compatibility in the future when they add support for longdesc"? |
| 00:28 | <TabAtkins> | Yes. Yes there is. |
| 00:31 | <Dashiva> | I'm going to need a bigger palm |
| 01:38 | <CrossX> | AryehGregor: I was told you could help me with FX's RTE https://developer.mozilla.org/en/rich-text_editing_in_mozilla |
| 01:39 | <CrossX> | When a user uses the RTE the HTML created appears on a single line instead of formated with \n's and \t's. Is there any way to get the HTML created in the RTE to appear 'beautyfied'. |
| 03:06 | <mpilgrim> | heycam: ping |
| 03:08 | <heycam> | mpilgrim, pong |
| 03:09 | <mpilgrim> | so i'm tightening up webkit's IDL implementation |
| 03:09 | <mpilgrim> | and aligning it with WebIDL |
| 03:09 | <mpilgrim> | slowly |
| 03:09 | <heycam> | cool! |
| 03:09 | <heycam> | are the V8 bindings still different from WebKit's? |
| 03:09 | <mpilgrim> | yes |
| 03:10 | <mpilgrim> | but both webkit and v8 are getting the new strictness |
| 03:10 | <mpilgrim> | is there a prescribed exception we should throw on missing required arguments? |
| 03:10 | <heycam> | yes, TypeError |
| 03:10 | <mpilgrim> | ok, we don't do that |
| 03:11 | <mpilgrim> | yet |
| 03:11 | <heycam> | ok |
| 03:11 | <mpilgrim> | well we don't do anything different yet |
| 03:11 | <mpilgrim> | the new strictness is still theoretical |
| 03:11 | <mpilgrim> | i'm migrating IndexedDB first |
| 03:14 | <heycam> | if you get on to migrating old apis, and find some that break compatibility when enforcing the strictness, it'd be good to turn those into spec bug reports |
| 03:14 | <heycam> | to make arguments optional |
| 03:14 | <mpilgrim> | we will be tackling APIs in this order: |
| 03:14 | <mpilgrim> | 1. IndexedDB |
| 03:15 | <mpilgrim> | 2. other new-ish APIs (web audio, File API) |
| 03:15 | <mpilgrim> | 3. older APIs that are known to have stricter implementations in other browsers (addEventListener) |
| 03:16 | <mpilgrim> | 4. older APIs that have poor or no x-browser interop (WebSQLDatabase) |
| 03:16 | <mpilgrim> | 5. older APIs that have unknown interop issues |
| 03:16 | <mpilgrim> | 6. SVG |
| 03:18 | <mpilgrim> | ok, i've changed our IDL code generator (A 3356-LINE PERL SCRIPT WITH VIRTUALLY NO UNIT TESTS) to throw TypeError instead of SyntaxError |
| 03:18 | <mpilgrim> | on missing required arguments |
| 03:18 | <heycam> | (I did some minor amount of hacking on that file in the past :( ) |
| 03:19 | <mpilgrim> | i added 3 lines and introduced 2 new bugs |
| 03:19 | <mpilgrim> | Perl is not my drug of choice |
| 03:20 | heycam | enjoys it, but really should learn python some day |
| 03:21 | <mpilgrim> | i have another (unrelated) WebIDL question |
| 03:21 | <mpilgrim> | on nulls |
| 03:21 | <heycam> | sure |
| 03:21 | <heycam> | (I have to head out in a couple of mins tho) |
| 03:21 | <mpilgrim> | I've read http://dev.w3.org/2006/webapi/WebIDL/#TreatNullAs |
| 03:22 | <mpilgrim> | it seems the only two choices are "" and "null" |
| 03:22 | <heycam> | yeah |
| 03:22 | <mpilgrim> | WebKit has this flag which I don't fully understand called ConvertNullToNullString |
| 03:22 | <mpilgrim> | which, in C++ land, makes the null JS argument an actual null value in C++ |
| 03:22 | <heycam> | I in the past wondered about that flag, too -- I never fully understood the distinction between null and a "null string" |
| 03:22 | <heycam> | oh |
| 03:22 | <mpilgrim> | well, it's poorly named, but that's what it does |
| 03:23 | <mpilgrim> | is there a WebIDL equivalent to that? |
| 03:24 | <heycam> | so the DOMString type only has values that are strings |
| 03:24 | <heycam> | if you want null in that type too, you can write "DOMString?" |
| 03:24 | <heycam> | you can't use [TreatNullAs] on "DOMString?" typed arguments |
| 03:24 | <heycam> | since null is a valid value of the type |
| 03:24 | <zewt> | the null string is the empty string, synonymous |
| 03:25 | <heycam> | zewt, I think it really depends on the context |
| 03:25 | <zewt> | can't think of any context where it means something else |
| 03:25 | <heycam> | zewt, i.e. people use the term "null string" differently |
| 03:25 | <heycam> | it could mean a null object reference |
| 03:25 | <zewt> | i'd say they're using it incorrectly, then |
| 03:26 | <zewt> | that's not the null string, that's just null |
| 03:26 | <mpilgrim> | yes, that's what it really is -- it takes the JavaScript value null and converts it to a null object reference in C++ |
| 03:26 | <heycam> | zewt, I think it's fair to stick to one particular definition of "null string", yes. :) |
| 03:26 | <mpilgrim> | i'm not sure we've implemented support for "?" |
| 03:26 | <mpilgrim> | ie "DOMString?" |
| 03:26 | <mpilgrim> | but i'll check |
| 03:26 | <heycam> | mpilgrim, ok sounds like "DOMString?" is what you want though |
| 03:26 | <mpilgrim> | awesome |
| 03:27 | <heycam> | the "?" has only been in Web IDL for maybe 6 months |
| 03:27 | <heycam> | but specs are just now starting to use it |
| 03:27 | <heycam> | ok gotta go, back in an hour or something |
| 03:27 | <zewt> | mpilgrim: if "ConvertNullToNullString" means "convert javascript null to ((std::string *) NULL)" or similar, it seems confusingly named at beset |
| 03:27 | <mpilgrim> | thanks |
| 03:27 | <heycam> | np |
| 03:31 | <mpilgrim> | zewt: yeah, well, i'm looking to do away with the flag altogether and align with WebIDL instead |
| 03:34 | <mpilgrim> | man, the downside of hacking on the IDL code generator is it has to reprocess 500+ IDL files and then recompile every time i change one line of perl |
| 03:36 | <zewt> | also, having to change lines of perl |
| 03:38 | <mpilgrim> | yes, another major downside |
| 04:02 | <MikeSmith> | I reckon that thing you pinged me about on IRC when I was away was http://www.w3.org/Bugs/Public/show_bug.cgi?id=12212 |
| 04:03 | <MikeSmith> | the JS problem with the feedback form |
| 04:03 | <MikeSmith> | anyway, yeah, it's fixed now |
| 04:27 | <mpilgrim> | heycam: so it turns out throwing TypeError is a bit more complicated than i'd hoped |
| 04:27 | <mpilgrim> | webkit currently throws SyntaxError when there aren't enough arguments |
| 04:29 | <mpilgrim> | every function that currently specifies [RequiresAllArguments=raise] (many in SVG, a few in canvas, one in XMLHttpRequest) is potentially affected |
| 04:29 | <mpilgrim> | that means i might be breaking the web |
| 04:29 | <mpilgrim> | which means i need some thorough review and buy-in first |
| 07:59 | <pererik> | Hixie: what I meant was that MediaStream could be made constructible with tracks as arguments (stop() doesn't make sense if the stream is composed of tracks from other streams) |
| 08:00 | <pererik> | Hixie: what could be problematic is that the availability of each track would have to be tracked and maybe exposed as a readyState or as a boolean property |
| 08:00 | <pererik> | Hixie: a boolean property makes sense if there are only two states |
| 08:01 | <pererik> | Hixie: also if the enabled/selected state ends up on the track objects they would have to be copied into the new stream so that they can be independently controlled |
| 09:31 | <annevk> | http://dev.w3.org/2009/dap/system-info/battery-status.html is anyone planning on implementing this? |
| 09:31 | <Ms2ger> | /dap/? I assume not |
| 09:34 | <Ms2ger> | Also, http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/764c9bbee7e22a52 |
| 09:46 | <pererik> | annevk: https://lists.webkit.org/pipermail/webkit-dev/2011-June/017120.html |
| 09:58 | <annevk> | thanks! |
| 10:13 | <smaug____> | Ms2ger: I think MS is quite interested in DAP work |
| 10:13 | <smaug____> | at least some parts of it |
| 10:13 | <smaug____> | I don't know why |
| 10:21 | <Ms2ger> | They do lots of weird stuff |
| 10:24 | <smaug____> | Ms2ger: actually, it sounded like they would like to use DAP's capturing API |
| 10:24 | <smaug____> | I assume that is because W3C HTML5 doesn't have capturing API, IIRC |
| 10:24 | <smaug____> | MS should just join whatwg |
| 10:25 | <Ms2ger> | Now that's something we can agree on :) |
| 10:27 | <annevk> | <input type=file> is a capturing API |
| 10:36 | <Peter`> | Isn't the only thing holding MS' joining back the lack of a patent policy? |
| 10:36 | <Peter`> | Well, the largest reason |
| 10:38 | <annevk> | seemed to be no problem for schema.org |
| 10:54 | <MikeSmith> | quake |
| 10:55 | <MikeSmith> | annevk: I thought that too |
| 10:55 | <MikeSmith> | but schema.org does actually have a patent policy |
| 10:55 | <MikeSmith> | read the "Terms and conditions" page |
| 11:02 | <annevk> | I see |
| 11:03 | <annevk> | well, I guess if Microsoft made an effort to join the WHATWG such a policy could be created for it too |
| 11:43 | <annevk> | any progress on Gecko removing mutation events as trial for a future Firefox release? |
| 11:47 | <Ms2ger> | No |
| 11:49 | <annevk> | smaug____, ^^ |
| 11:50 | <annevk> | apparently I'm using a nightly of Firefox 7, you'd expect some progress by now :p |
| 11:50 | <Ms2ger> | You know what's weird? We'll release Fx7 final this year :) |
| 11:51 | <smaug____> | annevk: sorry |
| 11:51 | <smaug____> | I should write the replacement implementation first |
| 11:52 | smaug____ | reviews a patch first and start implementing it |
| 12:18 | <smaug____> | annevk: just curious, what do you think about FunctionOnly? Since I'm having hard time to understand why it would be used ever (except perhaps for legacy API) |
| 12:18 | <annevk> | It makes the API surface simpler |
| 12:19 | <smaug____> | really? |
| 12:19 | <smaug____> | how |
| 12:19 | <annevk> | but it would also be simpler if we supported the same pattern everywhere |
| 12:19 | <annevk> | well, since you cannot do both function() {} and {handler:function(){}} |
| 12:19 | <annevk> | but just function(){} |
| 12:19 | <smaug____> | and it is simpler for who? |
| 12:20 | <annevk> | but supporting function and {} everywhere would be fine with me too |
| 12:20 | <annevk> | authors |
| 12:20 | <smaug____> | if some author doesn't care about { foo: function()}, there is no need to use it |
| 12:21 | <smaug____> | 'this' handling with { foo: function() {}} makes it just very handy |
| 12:21 | <annevk> | that doesn't make it simpler :) he still needs to chose |
| 12:21 | <annevk> | or she |
| 12:21 | <annevk> | yeah, so maybe we should support the {handler} thing everywhere? |
| 12:31 | <smaug____> | annevk: yes, IMO, we should support {} everywhere |
| 12:32 | <smaug____> | onfoo listeners could be, in theory, special case, because of how they have traditionally worked in browsers |
| 12:32 | <smaug____> | and I'm not sure about setTimeout/Interval |
| 12:42 | <hsivonen> | now that Opera has a dev channel equivalent, how long until Opera gets rid of minor version numbers |
| 13:08 | <MikeSmith> | hsivonen: when I have a minute I wanted to get your feedback on an idea about how to better handle the validator spec advice in error messages for input elements that have attributes that aren't allowed for their type |
| 13:11 | <hsivonen> | MikeSmith: what's the idea? |
| 13:11 | <hsivonen> | MikeSmith: or did you mean you don't have the minute now? |
| 13:12 | <hsivonen> | MikeSmith: anyway, the input element autoextracted advice is confusing enough that it might be worthwhile to special-case the input element and even emit hand-crafted advice |
| 13:12 | <MikeSmith> | bing |
| 13:12 | <MikeSmith> | *bingo |
| 13:12 | <MikeSmith> | that's what I was going to ask you about |
| 13:13 | <MikeSmith> | was thinking, basically, could add a hashmap in the message-emitter code |
| 13:14 | <MikeSmith> | with a string to hold the name of each input type, and an array of strings to hold the allowed attributes for that type |
| 13:14 | <hsivonen> | MikeSmith: makes sense |
| 13:15 | <MikeSmith> | OK |
| 13:15 | <MikeSmith> | I will try to get a patch written up for it this weekend |
| 13:16 | <hsivonen> | MikeSmith: cool |
| 13:19 | <MikeSmith> | hmm, http://www.koderapp.com/ |
| 13:20 | <MikeSmith> | after a few weeks of using an ipad, I have a hard time imaging to try to spend any significant time trying to write or edit code using it |
| 13:21 | <MikeSmith> | or generally, any touchscreen device without a real keyboard |
| 13:23 | smaug____ | doesn't remember if ipad gives tactile feedback when typing |
| 13:37 | <hsivonen> | hmm. should http://code.google.com/apis/webmastertools/docs/1.0/reference.html really count as a spec for "verify-v1" as a meta keyword? |
| 13:38 | <hsivonen> | http://www.google.com/support/webmasters/bin/answer.py?answer=35638#3 suggests a different keyword |
| 13:39 | <hsivonen> | http://www.google.com/support/forum/p/Webmasters/thread?tid=548b74c4eb6c44bf&hl=en suggests the old syntax still works |
| 14:00 | <erlehmann> | MikeSmith, i cannot even grok how people using a smartphone without a proper keyboard can type on it. my thumb ached after i tried it for like a week. |
| 14:00 | <erlehmann> | also, it's slooooooow |
| 14:04 | <MikeSmith> | erlehmann: yeah, though tablets have faster CPUs at least |
| 14:04 | <MikeSmith> | faster than smartphones |
| 14:05 | <MikeSmith> | smaug____: no tactile feedback on ipad |
| 14:05 | <MikeSmith> | just clicking sound |
| 14:05 | <erlehmann> | MikeSmith, implying that would matter with editors. i use NANO(1) on my g1. |
| 14:06 | <MikeSmith> | what's a g1? |
| 14:06 | <smaug____> | MikeSmith: tactile feedback might help with typing |
| 14:07 | <erlehmann> | MikeSmith, htc dream. |
| 14:07 | <erlehmann> | t-mobile branded name for it, in … europe? at least germany. |
| 14:07 | <MikeSmith> | erlehmann: ah |
| 14:08 | <MikeSmith> | smaug____: yeah, definitely. haptics I guess they call it |
| 14:08 | <erlehmann> | funny enough, it's “old”, but i have not found a smartphone with a decent keyboard yet. |
| 14:08 | <smaug____> | yup |
| 14:09 | <erlehmann> | also, the never ones do not have cheap plastic cases, so no monster batteries that make it look like a brick :B |
| 14:21 | <hsivonen> | the latest spec fur Dublin Core is awfully vague |
| 14:21 | <hsivonen> | how can anyone implement software that does something useful with DC? |
| 14:21 | <hsivonen> | do they just reverse engineer what others do? |
| 14:22 | <hsivonen> | or does no one actually implement useful software that uses DC? |
| 14:27 | <hsivonen> | sigh. validator.nu deployment broken again. html5.validator.nu works |
| 14:27 | <MikeSmith> | is there any software that actually does anything useful with DC? |
| 14:28 | <MikeSmith> | hsivonen: what broke? |
| 14:28 | <hsivonen> | MikeSmith: it doesn't pick up the changes when I try to deploy |
| 14:28 | <MikeSmith> | oh |
| 14:29 | <hsivonen> | MikeSmith: I'm not aware of such software (Re: DC) |
| 14:30 | <MikeSmith> | well, geez |
| 14:30 | <MikeSmith> | that says something, really |
| 14:30 | <MikeSmith> | I mean, if there are no widely-used apps that actually consumed that data |
| 14:31 | <hsivonen> | that I'm unaware doesn't mean they don't exist |
| 14:31 | <MikeSmith> | it would make it seem like a fairly massive waste of time for people to actually be adding it |
| 14:31 | <MikeSmith> | well, certainly seems like there's nothing very widely-known that does anything with it |
| 14:33 | <MikeSmith> | hsivonen: btw, in walking through the message-emitter code, I now see that for the case of the input element, there does not seem to be any way to determine in that part of the code what its type value is |
| 14:34 | <MikeSmith> | because the exceptions the jing generates don't have any methods for getting at the attribute information |
| 14:35 | <MikeSmith> | those exceptions only have methods for getting the element name and name of its parent |
| 14:37 | <MikeSmith> | so I guess I'm going to have to think about this a bit more |
| 14:41 | <hsivonen> | MikeSmith: :-( |
| 14:42 | <MikeSmith> | indeed :( |
| 14:42 | <MikeSmith> | may have to resort to scraping the extract |
| 14:45 | <hsivonen> | I'd rather punch some abstraction holes elsewhere than scrape the extract |
| 14:48 | <hsivonen> | http://dublincore.org/resources/faq/#whatsearchenginessupport |
| 14:51 | <MikeSmith> | chuckle |
| 14:51 | <MikeSmith> | "Blue Angel Technologies MetaStar" |
| 14:51 | <MikeSmith> | and "Verity Search 97 Information Server" |
| 14:51 | <MikeSmith> | okay |
| 14:53 | <MikeSmith> | I'll add a method to the jing abstract exception do get all the attributes |
| 14:53 | <MikeSmith> | James would probably love that |
| 14:55 | <gsnedders> | hsivonen: RSS consumors often use dc:date |
| 15:01 | <hsivonen> | gsnedders: with what meaning and what value formats? |
| 15:02 | <gsnedders> | hsivonen: Publication date (in place of the very badly implemented pubDate). Normally supporting W3CDTF. |
| 15:03 | <hsivonen> | gsnedders: ok |
| 15:03 | hsivonen | wonders what software uses "coverage" and for what |
| 18:31 | <MikeSmith> | "Incorporated Rhino CLI" https://github.com/stubbornella/csslint/blob/master/CHANGELOG |
| 18:31 | <MikeSmith> | wonder what that means |
| 18:33 | <gsnedders> | It's possible to run in Rhino, I believe, looking through the commits |
| 18:34 | <MikeSmith> | oh |
| 18:35 | <MikeSmith> | run _in_ rhino? |
| 18:35 | <MikeSmith> | is what it means"? |
| 18:35 | <gsnedders> | MikeSmith: Yeah. |
| 18:36 | <MikeSmith> | ok |
| 19:24 | <smaug____> | recompiling, and then first test with the mutation event replament. |
| 19:24 | <smaug____> | replacement |
| 19:53 | <Yuhong> | <Ms2ger> We should replace it with something purty and neat, all from scratch |
| 19:54 | <Yuhong> | Personally if I was there in 2004 I would have suggested a new version of XHTML that is tag level compatible with HTML4 and XHTML1. |
| 19:54 | <Yuhong> | As opposed to XHTML2 which was not. |
| 21:23 | <annevk> | Unread 2345 |
| 21:23 | <annevk> | making progress |
| 21:23 | <annevk> | I wonder when I reach 1337 |
| 21:24 | <Ms2ger> | Down from? |
| 21:24 | <annevk> | 19k |
| 21:25 | <Ms2ger> | Then I suspect soon :) |
| 21:26 | <annevk> | the first 10k was the easiest :) |
| 21:27 | <Ms2ger> | Also, I was happy to see you agreed with this editor :) |
| 21:32 | <annevk> | http://tools.ietf.org/html/draft-melnikov-mime-default-charset whoa |
| 21:33 | <annevk> | jreschke aligning some outdated spec with implementations rather than claiming the implementations are broken |
| 21:34 | annevk | makes a note for WHATWG Weekly |
| 21:37 | <Ms2ger> | If you hadn't seen it yet, https://github.com/andreasgal/dom.js |
| 21:38 | <annevk> | sweet |
| 21:39 | <annevk> | is this sponsored by Mozilla now he figured out just selling books does not work? :) |
| 21:39 | <annevk> | oh, David Flanagan was just the last to make a checkin |
| 21:43 | <Ms2ger> | Yes, I believe so |
| 21:45 | <annevk> | very cool |
| 21:46 | <Ms2ger> | Yeah, we're doing something new for once ;) |
| 21:46 | <annevk> | I saw in the logs experiments with removing mutation events are starting too |
| 21:47 | <annevk> | I wonder if the replacement needs to be part of DOM Core |
| 21:47 | <Ms2ger> | Probably |
| 21:54 | <annevk> | Ah, I found and replied to the email where bz rightly claims DOM Core would not be a proper specification without mutation events |
| 21:56 | <zewt> | annevk: by the way, recent discussion in here raised the question of how dom core should deal with those weird events where dispatching them causes default behavior (onclick in particular, onsubmit in everything but WebKit) ... not urgent, just mentioning it while I'm remembering it since it was off-list |
| 21:57 | <Ms2ger> | annevk, what do you think about document.ownerDocument, while you're in that thread? |
| 21:57 | <annevk> | oh yeah, I agree with Ian that submit is bug |
| 21:58 | <annevk> | Ms2ger, if we can change browsers, works for me |
| 21:59 | <annevk> | Ms2ger, that a Document owns itself makes sense to me :) |
| 21:59 | Ms2ger | adds a note |
| 21:59 | <annevk> | zewt, and I think I agree with you that we should just treat them as distinct concepts |
| 21:59 | <annevk> | zewt, dispatching and whatever you do if the event was not canceled |
| 22:03 | <jgraham> | mpilgrim: BTW I would love for the final argument to addEventListener to be optional, so let's try to fix the platform :) |
| 22:03 | <jgraham> | Also, commiserations on the perl |
| 22:04 | <annevk> | zewt, Ms2ger, also, I think using the empty string rather than a hidden flag is the way to go for uninitialized events |
| 22:04 | <annevk> | (re: long time ago) |
| 22:04 | <Ms2ger> | Tell smaug that :) |
| 22:04 | jgraham | knows no perl and was trying to add features to a largish, test-free, perl codebase the other day |
| 22:04 | <zewt> | i agree, figured I'd wait until you were back to grumble further about that |
| 22:04 | <zewt> | jgraham: my condolensces |
| 22:05 | <annevk> | jgraham, it's already optional |
| 22:05 | <annevk> | jgraham, see DOM Core |
| 22:05 | <gsnedders> | jgraham: It does have tests. About four. |
| 22:05 | <Ms2ger> | jgraham, been hacking on WebKit's IDL parser? |
| 22:05 | <jgraham> | annevk: Right. So let's not let mpilgrim make it non-optional in WebKit :) |
| 22:06 | <jgraham> | gsnedders: Not covering the bit I was modifying though |
| 22:06 | <jgraham> | I was *so* tempted to rewrite that bit in python and work out how to call perl from python... |
| 22:07 | <zewt> | heh, i rewrote all of my old perl stuff in python long ago, fortunately I've never written anything *big* in Perl |
| 23:42 | <paul_irish> | what's the TR in many spec URLs stand for? Technical Recommendation? |
| 23:42 | <gsnedders> | Yeah |
| 23:48 | <annevk> | no |
| 23:48 | <annevk> | Technical Report |