| 00:00 | <zewt> | sicking: it's an HTMLCollection in DOM4, and in that all four implementations agree |
| 00:00 | <rniwa> | sicking: hopefully we don't end up ping-pong each other's behavior |
| 00:00 | <rniwa> | zewt: wait but webkit doesn't return HTMLCollection, right? |
| 00:00 | <zewt> | according to "document.body.children instanceof HTMLCollection" |
| 00:01 | <zewt> | rniwa: it doesn't return it--talking about children *itself* being an HTMLCollection |
| 00:01 | <rniwa> | zewt: we just return an array |
| 00:01 | <rniwa> | zewt: ah, I see. right. |
| 00:01 | <sicking> | zewt: if by "all four" you exclude FF10 :) |
| 00:02 | <zewt> | sicking: all four production releases |
| 00:02 | rniwa | insists on us needing data for IE6, 7, & 8 |
| 00:02 | <zewt> | i don't have VMs for all of those it seems, testing 6 now |
| 00:02 | <rniwa> | zewt: thanks |
| 00:02 | <sicking> | zewt: hmm.. it appears to be in FF10 as well.. bummer |
| 00:03 | <rniwa> | sicking: that's good though |
| 00:03 | <rniwa> | sicking: that means all browsers agree on that |
| 00:03 | <sicking> | zewt: ouch, we even still make getElementsByTagName return a HTMLCollection :( |
| 00:04 | <sicking> | rniwa: HTMLCollection is a very messy API. I almost think it's strictly worse than NodeList |
| 00:05 | <zewt> | 2011 and i'm debugging code to make it work in ie6 |
| 00:05 | <zewt> | kill me |
| 00:05 | <Hixie> | just let it break, man |
| 00:05 | <rniwa> | sicking: you make it sound as if NodeList is a good API :P |
| 00:05 | <zewt> | Hixie: the point is testing code for the above :) |
| 00:07 | <bga> | infinite redirect on facebook :/ |
| 00:07 | <rniwa> | sicking: caching nodes for NodeList is just a nightmare |
| 00:07 | <rniwa> | sicking: it's the reason inserting a node is O(depth of tree) in WebKit at the moment |
| 00:08 | <zewt> | rniwa: ie6 doesn't have HTMLCollection at all, and all four cases return an array-like object with two items |
| 00:08 | <rniwa> | zewt: ah I see |
| 00:08 | <rniwa> | zewt: but still consistent with being it array-like |
| 00:08 | <zewt> | right |
| 00:08 | <rniwa> | zewt: so I think we have a clear compat. issue here |
| 00:10 | <zewt> | also, namedItem is less clear |
| 00:11 | <zewt> | in IE6 it returned an array, in IE9 it returns a single item (matching FF); Chrome and Opera still return arrays |
| 00:11 | <rniwa> | zewt: :( |
| 00:11 | <zewt> | smells like IE changing to match the spec but the spec was wrong |
| 00:11 | <rniwa> | zewt: yeah... |
| 00:11 | <rniwa> | zewt: they might need to play a ping-pong here. |
| 00:12 | <zewt> | it's odd that IE9 *only* changed to match the spec for namedItem and not the others, though |
| 00:12 | <zewt> | maybe that was the only one they could change without breaking lots of pages |
| 00:14 | <rniwa> | zewt: could be. |
| 00:14 | <rniwa> | zewt: i mean they should be told us it won't work |
| 00:14 | <rniwa> | zewt: then we didn't have to wait 'til now to figure this out :( |
| 00:14 | <rniwa> | should have* |
| 00:15 | <zewt> | rniwa: and not inconsistently changing one part of a tightly-related API and just confusing things further |
| 00:15 | <rniwa> | or that spec authors should have paid more attention.. |
| 00:15 | <rniwa> | zewt: yeah, |
| 00:15 | <rniwa> | zewt: just changing the behavior of namedItem is way too confusing |
| 00:15 | <zewt> | if the implementors aren't giving back feedback (I wouldn't know either way) then there's only so much the editors can do |
| 00:16 | <zewt> | (MS people--not all of them--seem to be in that group of people who wait until LC then give two years of withheld feedback all at once) |
| 00:17 | <sicking> | rniwa: that's not a NodeList problem |
| 00:17 | <sicking> | rniwa: you'd have the same problem if .childNodes was a HTMLCollection |
| 00:17 | <rniwa> | sicking: right. |
| 00:17 | <rniwa> | sicking: so I think all of those are bad APIs |
| 00:17 | <Hixie> | zewt: your definition of "two years of withheld feedback" is much smaller than mine... |
| 00:18 | <sicking> | rniwa: additionally, lots of things will force you to walk the parent chain when inserting nodes |
| 00:18 | <sicking> | rniwa: so it's not a .childNodes problem either really |
| 00:18 | <sicking> | rniwa: MutationObservers will force you to do the same |
| 00:18 | <zewt> | well, i seem to recall seeing them dump feedback in response to CfC's (making me think: why did you wait?) |
| 00:18 | <sicking> | rniwa: as do ranges likely |
| 00:19 | <rniwa> | sicking: sure. but we should be able to insert nodes in O(1) as long as there are no ranges and no observers |
| 00:19 | <zewt> | (or whatever magic TLA it is they use when calling for updating drafts) |
| 00:19 | <rniwa> | sicking: which is fairly common |
| 00:20 | <rniwa> | sicking: we're thinking to have some hash map for selection, focus, etc... |
| 00:20 | <rniwa> | sicking: but most of those things need to happen at removal |
| 00:20 | <rniwa> | sicking: e.g. inserting a node shouldn't require DOM traversal for ranges |
| 00:21 | <zewt> | anyway just my impression from the outside, i'm not an editor tearing out my hair at this stuff :) |
| 00:21 | <rniwa> | zewt: we just need to split spec into smaller pieces |
| 00:21 | <rniwa> | zewt: and push them into LC as soon as possible |
| 00:22 | <sicking> | rniwa: shrug. I don't think that walking the parent chain would be a big deal in most cases |
| 00:22 | <rniwa> | sicking: it actually is. |
| 00:22 | <rniwa> | sicking: I've found that most trees have depths of 5-20 |
| 00:22 | <rniwa> | sicking: but walking all those nodes on every node insertion is quite expensive |
| 00:22 | <sicking> | rniwa: it's just a linked list |
| 00:23 | <sicking> | and 20 is pretty short |
| 00:23 | <rniwa> | sicking: simply because loading the node into memory may invalidate L1/L2 caches in the CPU |
| 00:23 | <zewt> | linked lists are notoriously troublesome for cache... |
| 00:23 | <sicking> | you'll likely have to access the node anyway when laying it out |
| 00:23 | <rniwa> | sicking: sure. |
| 00:23 | <rniwa> | sicking: layout is super duper slow |
| 00:23 | <zewt> | (though that can be alleviated with some/a lot of work) |
| 00:24 | <rniwa> | sicking: but we should make DOM operation as fast as possible nonetheless |
| 00:24 | <sicking> | i don't actually know if walking the parent chain shows up in profile for us. I think most of the time it doesn't |
| 00:24 | <sicking> | but i'm not fully sure |
| 00:24 | <sicking> | bz would know |
| 00:26 | <rniwa> | sicking: in most pages it doesn't. |
| 00:26 | <rniwa> | sicking: but gmail, for example, spends 80-90% of its loading time in making DOM mutations |
| 00:27 | <zewt> | heh, gmail being the only web app i've ever used that actually takes so long to start up it needs a progress bar for it |
| 00:28 | <sicking> | haha |
| 00:29 | <rniwa> | anyway, I think making DOM operations faster is a good thing |
| 00:30 | <rniwa> | and we should make sure we don't introduce new APIs that makes everything slower |
| 00:31 | <zewt> | rniwa: are you going to file a bug about changing HTMLCollection in dom4? |
| 00:31 | <zewt> | don't know whether to recommend the results be NodeList or HTMLCollection |
| 00:32 | <zewt> | (that's the lesser problem, though) |
| 00:32 | <rniwa> | zewt: I think you should file one since you have a test |
| 00:33 | <zewt> | k |
| 00:39 | <zewt> | anyone have FF8 to test? |
| 00:39 | <zewt> | (to narrow where the namedItem change was made) |
| 00:41 | <rniwa> | zewt: I have FF7... |
| 00:42 | <zewt> | that'd get closer... |
| 00:43 | <rniwa> | document.body.children is an HTMLCollection: true |
| 00:43 | <rniwa> | document.body.children["x"]: [object XrayWrapper [object HTMLDivElement]] undefined HTMLElement |
| 00:43 | <rniwa> | document.body.children.item("x"): [object XrayWrapper [object HTMLDivElement]] undefined HTMLElement |
| 00:43 | <rniwa> | document.body.children.namedItem("x"): [object XrayWrapper [object HTMLDivElement]] undefined HTMLElement |
| 00:43 | <rniwa> | document.body.children.x: [object XrayWrapper [object HTMLDivElement]] undefined HTMLElement |
| 00:43 | <rniwa> | (FF7) |
| 00:43 | <rniwa> | now onto FF8 |
| 00:43 | <zewt> | err |
| 00:43 | <zewt> | sorry, I meant IE7 |
| 00:44 | <rniwa> | zewt: oh IE7 |
| 00:44 | <zewt> | to narrow where IE made the namedItem change we talked about before |
| 00:44 | <zewt> | (not a huge data point, but worth noting) |
| 00:44 | <rniwa> | no i don't... |
| 00:46 | <rniwa> | zewt: if you have a windows machine, you can download these images: http://www.microsoft.com/download/en/details.aspx?id=11575 |
| 00:46 | <zewt> | yuck, trying to undo a lot in gmail's editor is *painful* |
| 00:46 | <zewt> | hold down ^Z, go get a sandwich |
| 00:46 | <zewt> | like 1/3 second per undo |
| 00:47 | <rniwa> | zewt: oh dear... |
| 00:47 | <rniwa> | ojan: ^ |
| 00:47 | <rniwa> | zewt: on which UA? |
| 00:47 | <zewt> | (started typing a mail, decided to copy my text and undo to get the original quotes back) |
| 00:48 | <ojan> | rniwa: ? |
| 00:48 | <zewt> | FF8, html editor |
| 00:48 | <rniwa> | ojan: zewt tells me undo on gmail is super slow (takes 1/3 second) |
| 00:48 | <zewt> | slow enough that i held ^Z for a while, came here to grumble about it, and it was still going when I tabbed back :) |
| 00:49 | <rniwa> | zewt: I think gmail recently switched not to use iframes for editors |
| 00:49 | <rniwa> | zewt: in "new look" |
| 00:49 | <rniwa> | zewt: so that might be theculprit. |
| 00:49 | <zewt> | (replying to hixie's 100-page mails is seriously painful in gmail's editor, but this is just two paragraphs) |
| 00:49 | <zewt> | rniwa: havn't switched to "new look" (since google "new looks" are always ... not good) |
| 00:49 | <Hixie> | pine baby |
| 00:50 | <zewt> | Hixie: given the choice of pains... :) |
| 01:02 | <zewt> | rniwa: sort of funny to see Microsoft distributing tools as RARs |
| 01:02 | <gsnedders> | Hixie: you want to know if skipping whitespace in atob causes issues? |
| 01:02 | <Hixie> | gsnedders: i did a search of the bts without seeing any problems |
| 01:03 | <Hixie> | gsnedders: so i'm guessing the answer is that it was fine in practice |
| 01:03 | <gsnedders> | Hixie: That's about all I can do |
| 01:03 | <gsnedders> | Hixie: So I guess so |
| 01:03 | <Hixie> | well i updated the spec |
| 01:03 | <Hixie> | to match opera |
| 01:04 | <Hixie> | i'm amused by the e-mail i just sent that mentions a bug that i wontfixed back in 2000 |
| 01:04 | <Hixie> | while interning at netscape |
| 01:04 | <gsnedders> | Hixie: You're aware of CORE-38656? |
| 01:04 | <gsnedders> | I presume you found that. |
| 01:05 | <gsnedders> | Which was the original change based upon your proposal to not throw for whitespace. |
| 01:05 | <gsnedders> | But yeah, nothing seems to break. |
| 01:05 | <Hixie> | yeah zcorpan posted that to the whatwg list which is what led me to have the question |
| 01:06 | <gsnedders> | I can't even find the prior evidence for not throwing breaking stuff, though I remember seeing bug reports about it |
| 01:07 | <Hixie> | my evidence was you saying so :-P |
| 01:08 | <gsnedders> | Yeah, I know that was your evidence. |
| 01:08 | <zewt> | heh, i've talked to someone on mailing lists, gone "uh where have I seen this name before", and realized that it was someone I had talked to on some other mailing list literally exactly one decade earlier |
| 01:08 | <gsnedders> | I just can't find the bugs. :P |
| 01:08 | <Hixie> | oh well |
| 01:10 | <Hixie> | bbl. |
| 01:10 | <gsnedders> | see ya |
| 01:19 | <gsnedders> | Hixie: Oh, throwing for non-ASCII chars? That's CORE-36226 and all of the dupes |
| 01:19 | gsnedders | is blatantly too tired |
| 01:35 | <zewt> | geeh |
| 01:36 | <zewt> | rniwa: the result type of these methods depends on whether there's one result or more than one |
| 01:36 | <rniwa> | hehehe. great. |
| 01:36 | <zewt> | i'd go with D: |
| 01:37 | <zewt> | opera doesn't change behaviors |
| 01:37 | <rniwa> | zewt: maybe IE behaves differently depending on whether it's on strict mode or not LOL |
| 01:37 | <zewt> | well IE6 probably behaves differently depending on if you fed it after midnight |
| 01:37 | <zewt> | okay that's a bad comparison because IE6 isn't normally cute and fuzzy |
| 01:38 | <zewt> | i think the weird changing return type is isolated to old IE |
| 01:38 | <zewt> | waiting for giganto images to finish downloading to find out how isolated |
| 01:54 | <zewt> | rniwa: ... sorry, no, looks like the difference is pretty common |
| 01:54 | <zewt> | (opera, chrome) |
| 01:56 | <MikeSmith> | http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-00 |
| 01:56 | <MikeSmith> | "Representing IPv6 Zone Identifiers in Uniform Resource Identifiers" |
| 02:00 | <zewt> | rniwa: https://zewt.org/~glenn/test-htmlcollection-results.html so looks like the only differences are when there are duplicate ids, which is a much smaller problem (nonconforming anyway) |
| 02:12 | <heycam> | AryehGregor, ping |
| 02:34 | <zewt> | bugzilla bitching at me for using the same form to file two bugs. heh |
| 03:22 | <heycam> | AryehGregor, when are you around, would you mind commenting on https://www.w3.org/Bugs/Public/show_bug.cgi?id=14887#c3 please. |
| 03:26 | <heycam> | annevk, in your reply http://www.w3.org/mid/op.v6g563va64w2qv⊙al does that mean I should not bother with making non-Array and Array objects distinguishable for now? |
| 03:26 | <heycam> | annevk, (as well as not worrying about defining dictionary<DOMString>?) |
| 07:51 | <annevk> | heycam|away: yeah |
| 08:33 | <annevk> | http://twitter.com/bz_moz/status/147229432275415041 context? |
| 08:38 | <hsivonen> | annevk: probably http://groups.google.com/group/mozilla.dev.platform/msg/6000e4ce6d744531 |
| 08:38 | <hsivonen> | annevk: and some German news site writing a story about that thread |
| 08:38 | <hsivonen> | annevk: my guess about context could be wrong |
| 08:38 | <hsivonen> | but unlikely |
| 08:40 | <hsivonen> | annevk: http://www.golem.de/1112/88347.html |
| 08:41 | <hsivonen> | annevk: contrast with https://twitter.com/#!/eevee/status/147018826712756225 |
| 08:45 | <annevk> | good times |
| 09:16 | <MikeSmith> | very cool to see responseType=json going into Firefox 10 |
| 09:17 | <MikeSmith> | hsivonen: you got bugs left to fix on View Source? |
| 10:41 | <hsivonen> | MikeSmith: one regression left in View Source |
| 10:41 | <hsivonen> | MikeSmith: plus a bunch of features that it logically should have but doesn't |
| 10:41 | <MikeSmith> | OK |
| 10:42 | <hsivonen> | if you aren't using the built-in View Source viewer and are using an external app via a hidden pref, clicking links from the Error Console doesn't work |
| 10:42 | <MikeSmith> | oh |
| 10:43 | <hsivonen> | yay hidden prefs that I had no idea existed when I was developing the new View Source |
| 10:43 | <MikeSmith> | heh |
| 11:04 | <hsivonen> | how does one get to activate New New Twitter? |
| 11:10 | <MikeSmith> | hsivonen: I don't think you can |
| 11:10 | <MikeSmith> | you must wait to be chosen |
| 11:11 | <MikeSmith> | what's a "threaded web application"? |
| 11:11 | <hsivonen> | MikeSmith: ok |
| 11:11 | <hsivonen> | MikeSmith: any context for "threaded web application"? |
| 11:12 | <hsivonen> | MikeSmith: a Web app that uses Workers maybe? |
| 11:12 | <MikeSmith> | http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm |
| 11:18 | <hsivonen> | MikeSmith: seems to me it means Workers |
| 11:18 | <MikeSmith> | hmm, OK |
| 11:18 | <MikeSmith> | they should say "workers" then |
| 11:18 | <hsivonen> | it would be clearer if it just said "Workers" |
| 11:18 | <MikeSmith> | yeah |
| 11:18 | <hsivonen> | yeah |
| 11:19 | <MikeSmith> | especially since workers are not threads... |
| 11:19 | <hsivonen> | depends on implementation |
| 11:21 | <MikeSmith> | I mean as far as the API exposed to Web apps |
| 11:22 | <MikeSmith> | at the JS level |
| 12:01 | <annevk> | oops |
| 12:02 | <hsivonen> | annevk: ? |
| 12:04 | <annevk> | had a bug in my encoding source data |
| 12:07 | <annevk> | added http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#preface |
| 12:30 | <matjas> | was `doctype` technically allowed to be lowercase in previous versions of HTML? |
| 12:40 | <zcorpan> | yes |
| 12:42 | <smaug____> | is it invocation or invokation ? |
| 12:42 | <smaug____> | I would assume with c |
| 12:42 | <smaug____> | websocket spec has invokation |
| 12:42 | <zcorpan> | the protocol? |
| 12:42 | <smaug____> | api |
| 12:42 | <zcorpan> | ah |
| 12:42 | <zcorpan> | yeah it's with c |
| 12:43 | <zcorpan> | unless the spec wanted to hotswap to swedish for one word |
| 12:50 | <smaug____> | websocket::send is bad |
| 12:50 | <smaug____> | it is strange to close the connection so easily |
| 12:59 | <zcorpan> | you mean when the buffer is full? |
| 13:08 | <smaug____> | yeah |
| 13:08 | <smaug____> | I think that handling should be different |
| 13:09 | <smaug____> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15209 |
| 13:19 | <zcorpan> | it also says to increase bufferedAmount even if the connection is closed |
| 13:20 | <zcorpan> | since it doesn't throw |
| 13:20 | <hsivonen> | matjas: HTML that pretended to be SGML allowed lower case. HTML that pretended to be XML didn't. |
| 13:56 | <annevk> | *summon Ms2ger* |
| 13:56 | annevk | wonders what the typical response time is for "summon" |
| 14:09 | <annevk> | renamed the encodings to just use the iso- names http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html |
| 14:09 | <annevk> | 8858-9 and -11 are missing as they are actually a windows- encoding |
| 14:09 | <annevk> | oh, and -1 is too |
| 14:09 | <annevk> | and -12 does not exist |
| 14:17 | <smaug____> | has anyone reviewed "File API: Directories and System" ? |
| 14:17 | <smaug____> | and, btw, is any of that implemented elsewhere than in Chrome |
| 14:18 | <annevk> | I think sicking objected to that |
| 14:18 | <annevk> | Apple did not seem interested either |
| 14:18 | <annevk> | (sicking wanted to use Indexed DB instead) |
| 14:18 | <annevk> | dunno about Opera, we have something similar so I guess there's some interest |
| 14:18 | <smaug____> | yeah |
| 14:19 | <smaug____> | but no one has reviewed the spec? I don't recall much discussion about that spec in web apps wg |
| 14:19 | <annevk> | it was discussed during some of the meetings, but mostly on the level of, "do we actually want to go there" |
| 14:21 | <matjas> | HTML5 doesn’t seem to allow `<p//` instead of `<p></p>` anymore — anyone got a spec link for that? or is that hidden away in the parsing algo? |
| 14:22 | <annevk> | matjas: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#start-tags |
| 14:24 | <matjas> | annevk: thanks |
| 14:38 | <MikeSmith> | annevk: do the following look like what we need? |
| 14:38 | <MikeSmith> | http://trac.webkit.org/browser/trunk/LayoutTests/fast/url |
| 14:39 | <MikeSmith> | e.g., http://trac.webkit.org/export/102933/trunk/LayoutTests/fast/url/anchor.html |
| 14:47 | <annevk> | MikeSmith: yeah |
| 14:47 | <annevk> | MikeSmith: those combined with abarth's sketch might go a long way towards defining URLs |
| 14:47 | <MikeSmith> | excellent |
| 14:47 | <MikeSmith> | so I'll ping abarth later |
| 15:08 | <kuya> | can i ask something about validator.nu here? |
| 15:13 | <MikeSmith> | kuya: yes |
| 15:13 | <MikeSmith> | so, for ES6, seems that engines are going to need to need to do mode-switching |
| 15:13 | <MikeSmith> | https://lists.webkit.org/pipermail/webkit-dev/2011-December/018903.html |
| 15:13 | <matjas> | what’s the correct name for the “URL part” after the formal public identifier in <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">;? |
| 15:14 | <bga> | or embed different engines |
| 15:14 | <bga> | but single bytecode |
| 15:14 | <kuya> | im sending a multipart/form request with a field called content to validator.nu but whatever i do cant get it to return anything but html output. iv tried adding it to the url and to the form data but no joy - does it actually work? |
| 15:14 | <zcorpan> | matjas: transitional doesn't need <p> |
| 15:15 | <matjas> | zcorpan: i know, just want to learn the correct technical name |
| 15:15 | <matjas> | oooh no i didn’t know that |
| 15:16 | <matjas> | zcorpan: http://validator.w3.org/#validate_by_input says <!DOCTYPE html PUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN"><title// is invalid |
| 15:16 | <MikeSmith> | matjas: I think you mean the "system ID"? |
| 15:16 | <MikeSmith> | kuya: yeah, it works |
| 15:16 | <MikeSmith> | gimme a minute to fine an example |
| 15:16 | <kuya> | MikeSmith: i just read the bit i was doing wrong! |
| 15:16 | <matjas> | MikeSmith: it is still called “System ID” if it’s a PUBLIC identifier? |
| 15:17 | <matjas> | zcorpan: I suppose that’s a bug in the W3C Validator then? |
| 15:17 | <MikeSmith> | the public ID is the non-URL part |
| 15:17 | <kuya> | MikeSmith: it didnt work in the url but i was specifying out=json after the content=<whatever> |
| 15:17 | <matjas> | MikeSmith: oh, i see |
| 15:17 | <zcorpan> | matjas: it needs body content |
| 15:17 | <MikeSmith> | kuya: I see. So you ahve it working now? |
| 15:17 | <kuya> | "The content field must be the last field in the submission. " was what i was missing |
| 15:17 | <kuya> | what a strange prerequisite |
| 15:18 | <matjas> | zcorpan: gotcha. <!DOCTYPE html PUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN"><title//x it is |
| 15:18 | <matjas> | zcorpan: thanks! |
| 15:21 | <MikeSmith> | kuya: fwiw, when I test the REST API with curl, I run it like this: curl --data-binary @foo.html -H "Content-Type: text/html" "http://localhost:8888/?out=gnu"; |
| 15:22 | <zcorpan> | matjas: are you sure iso html doesn't allow omitting tags etc? |
| 15:22 | <annevk> | I think I created a test of some sorts |
| 15:22 | <kuya> | iv been trying to validate bits of html via a browser in some sort of automated way |
| 15:23 | <kuya> | which turns out to be quite a pita with jquery |
| 15:23 | <hsivonen> | sigh. <!DOCTYPE html><math><mtext><p><i></p>a |
| 15:23 | <matjas> | zcorpan: not sure at all, but validator.w3.org says it’s invalid |
| 15:24 | <hsivonen> | matjas: system identifier |
| 15:25 | <matjas> | thanks |
| 15:25 | <zcorpan> | matjas: Note that the xmlns attribute on the root <html> element isn’t required in this version of XHTML. [citation needed] |
| 15:26 | <matjas> | zcorpan: no citation, just the result of trial and error using validator.w3.org :') |
| 15:26 | <zcorpan> | i see |
| 15:26 | <hsivonen> | kuya: the validator wants to ingest the form data in a streaming way in case the document is huge. it doesn't reorder fields on the server, so it wants to see the fields that set up the validation options before it seess the document |
| 15:27 | <matjas> | zcorpan: is it a validator bug? |
| 15:27 | <hsivonen> | matjas: xmlns is required if the recipient isn't processing external entities |
| 15:27 | <hsivonen> | matjas: it's an XML design bug |
| 15:27 | <matjas> | hah |
| 15:27 | <hsivonen> | matjas: or a design bug in the XHTML 1.0 DTD, depending on your world view |
| 15:28 | <zcorpan> | matjas: dunno, i try not to spend my time on reading XHTML2 WG deliverables these days |
| 15:28 | <hsivonen> | matjas: the DTD, if processed, implies the attribute on the XML 1.0 layer before the XMLNS layer does its thing |
| 15:29 | <hsivonen> | matjas: but XML doesn't guaranteed DTD processing |
| 15:29 | <kuya> | hsivonen: i see, fair enuff. it was there in the docs so its my own fault :) |
| 15:29 | <hsivonen> | s/d// |
| 15:30 | <hsivonen> | Opera is more compliant than Firefox with <!DOCTYPE html><math><mtext><p><i></p>a |
| 15:30 | <matjas> | i ♥ these hardcore write-up reviews |
| 15:30 | <annevk> | not exactly fast... http://dump.testsuite.org/encoding/single-octet-test.html |
| 15:30 | <annevk> | dreamhost latency |
| 15:51 | <hsivonen> | MikeSmith: an out of band mode switch for JS seems like a bad thing |
| 15:59 | <MikeSmith> | hsivonen: yeah |
| 15:59 | <MikeSmith> | but sounds like that's where things are headed |
| 16:04 | <zewt> | isn't the script type effectively deprecated, given that you can't even specify it with worker ctors, importScripts, etc |
| 16:05 | <zewt> | i guess you could restrict to importing scripts of the same version, but that would be pretty nasty |
| 16:05 | <annevk> | someone should inform TC39 how ECMAScript is used in a browser... |
| 16:05 | <zewt> | the mere idea of having to specify @type to <script> again would make me want to throw food |
| 16:05 | <annevk> | vacuum dev-- |
| 16:08 | <annevk> | is anyone going to take that up with es-discuss? |
| 16:09 | <matjas> | omg, forgot that doctype is optional in XHTML |
| 16:10 | <annevk> | matjas: not cool |
| 16:11 | <matjas> | ლ(ಠ益ಠლ) y u no tell me‽ |
| 16:14 | <zewt> | having one person suggest mislabelling caption tracks in webvtt as metadata tracks (and write your own cue renderer in javascript) and having someone@microsoft nod agreement makes me sad for the world |
| 16:18 | <ksweeney> | yeah i saw that :-/ |
| 16:32 | <annevk> | zewt: filed https://bugs.webkit.org/show_bug.cgi?id=74610 on removing UTF-7 and UTF-32 from Webkit/Chromium |
| 16:33 | <zewt> | cool, see how it goes |
| 16:34 | <annevk> | I wonder if I should first start defining multi-octet encodings by reference with rules on top |
| 16:34 | <zewt> | annevk: obscure as it is, trying to get them to either fix or remove ibm864 would be nice, since it's the only encoding here that screws with the ASCII range |
| 16:34 | <annevk> | zewt: you mean Gecko? |
| 16:34 | <zewt> | anything else come to mind (outside of wide encodings) that breaks the "all encodings are supersets of ascii" rule? |
| 16:35 | <zewt> | actually, both, i guess :( |
| 16:35 | <annevk> | ooh yes |
| 16:35 | <annevk> | WebKit/Chromium has some weird shit going on for all IBM encodings |
| 16:35 | <zewt> | that's such an insanely noninteroperable encoding (remapping %? really?) that it seems to strongly suggest no to "is this encoding in use" |
| 16:36 | <zewt> | oh yeah didn't notice the one in ibm866 |
| 16:36 | <annevk> | but Chromium only supports ibm864 and I think it is only because of WebKit, not because they want to |
| 16:36 | <annevk> | and Gecko supports a whole lot of IBM encodings |
| 16:37 | <zewt> | muh |
| 16:37 | <zewt> | doesn't seem worth spending a lot of time pushing uphill for those encodings, but nailing down the ASCII range would be a nice win |
| 16:37 | <annevk> | but that does not seem needed for interoperability |
| 16:38 | <annevk> | given that Chrome does not support ibm866 and Opera does not support ibm864 I think we can get all IBM stuff removed |
| 16:47 | <annevk> | kind of weird |
| 16:47 | <annevk> | whenever you file a bug on WebKit it's like it goes into a void unless you find some people to cc |
| 16:47 | <annevk> | whenever you file a bug on Gecko a whole bunch of people are paying attention |
| 16:48 | <zewt> | though that doesn't necessarily mean anyone who can do anything with it :P |
| 16:49 | <Velmont> | annevk: People have a similar WebKit experience with Opera and IE, I guess. |
| 16:49 | <annevk> | yeah :( |
| 16:49 | <zewt> | well, you'll have that with any large project; how often is more the question |
| 16:50 | <annevk> | after I saw what happened with the bugs zcorpan submitted to IE I stopped bothering |
| 16:50 | <Velmont> | annevk: What happened? |
| 16:54 | <annevk> | Velmont: resolved WONTFIX because they didn't make it for the release... |
| 16:54 | <zewt> | very... stereotypically microsoft |
| 16:55 | <Velmont> | ... :| |
| 16:55 | <MikeSmith> | Velmont, hey, you got my message about the W3C mercurial repo? |
| 16:55 | <MikeSmith> | you should be set up with perms to push to that repo now |
| 16:56 | <MikeSmith> | can't remember now which one it was |
| 16:56 | <MikeSmith> | but whatever one you asked about |
| 16:56 | <Velmont> | MikeSmith: Yep! I moved webkit tests into submissions/. I've been stalled on other stuff now. :-) But I'm actually looking through them now. |
| 16:56 | <MikeSmith> | cool |
| 16:56 | <Velmont> | MikeSmith: I'm a bit too afraid to just push, -- but, well, release early and often, can iterate and fix stuff later I guess ,-) |
| 16:56 | <MikeSmith> | yep |
| 16:57 | <MikeSmith> | that's what the submissions area's for, anyway |
| 16:58 | <smaug____> | filing Opera bugs has been really difficult. Few times the form has just failed (giving some server errors), and other times I've got some emails asking more information, but that is quite annoying way to handle bugs |
| 16:59 | <smaug____> | Opera should just open their bug database ;) |
| 16:59 | <zewt> | no browser's bug handling makes me very inclined to file bugs |
| 17:00 | <zewt> | i do from time to time but they're all ... unmotivating |
| 17:00 | <MikeSmith> | we clearly need to gamify bug-filing |
| 17:00 | <zewt> | heh |
| 17:00 | <MikeSmith> | badges.. |
| 17:01 | <MikeSmith> | achievements unlocked |
| 17:01 | <smaug____> | there should be some common bug database for browser bugs, at least for cases when browsers don't implement some API |
| 17:02 | <smaug____> | the bug could have fields for different browser engines. |
| 17:03 | <zewt> | sounds more like a reference registry than a bug tracker |
| 17:04 | <smaug____> | well, whatever it is called |
| 17:04 | <smaug____> | Mozilla uses bugzilla for everything |
| 17:04 | <Velmont> | Sooo... When we have a nice big w3c-test.org with a cool test runner and all, that can be a nice reference :-) |
| 17:05 | <annevk> | I guess at some point I should tell whatwg⊙wo about the encoding standard... |
| 17:05 | <zewt> | shhh |
| 17:06 | <annevk> | it's not exactly a secret, but still :) |
| 17:06 | <zewt> | i'm afraid to find out what error handling interop looks like for multibyte encodings |
| 17:07 | <zewt> | at least most encodings don't have as many error cases as utf-8, so there aren't quite so many ways they can differ |
| 17:24 | <kennyluck> | annevk5, that's pretty much my experience submitting patches to Mozilla/WebKit. I guess the following data might explain this somehow. |
| 17:26 | <kennyluck> | Summarizing 175 emails randomly selected from www-style: 31.4% Unkown Affliation, 24.6% Mozilla (5 people), 22.9% Google (1 people, that is TabAtkins), 13.7% Opera (3 people), 2.3% Microsoft (2 people), 1.1% Apple (1 person). |
| 17:28 | <kennyluck> | I guess you get similar figures if you count mails from whatwg⊙wo too. |
| 17:28 | <kennyluck> | Well, except Micorsoft. |
| 17:30 | <smaug____> | I'd guess Opera gets higher numbers in WhatWG |
| 17:35 | <Ms2ger> | annevk5, in this case about 3h30 |
| 17:53 | <Velmont> | annevk5: http://dvcs.w3.org/hg/webappsec/rev/8a0775f6d0eb |
| 18:03 | <annevk> | Velmont: sweet |
| 18:04 | <annevk> | Velmont: did you tweet it? |
| 18:04 | <Velmont> | Will do, -- but sending email first. |
| 18:04 | <annevk> | way to set your priorities :p |
| 18:12 | <annevk> | Ms2ger: what was the problem with patching Gecko for the encoding stuff? |
| 18:12 | <annevk> | Ms2ger: you said something earlier about a table that was hard to comprehend |
| 18:13 | <Ms2ger> | http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvlatin/cp874.ut |
| 18:14 | <annevk> | Ms2ger: also, what about http://krijnhoetmer.nl/irc-logs/whatwg/20111215#l-1037 ? |
| 18:14 | <Ms2ger> | Don't know anything about multi-byte encodings |
| 18:16 | <annevk> | Ms2ger: that is a weird table |
| 18:18 | <annevk> | Ms2ger: it does seem like you should simply replace the FFFDs in that table with the code points from the standard |
| 18:18 | <zewt> | weird but understandable, with a bit of squinting |
| 18:18 | <annevk> | Ms2ger: but then it says that file is generated so maybe you should fix the source file |
| 18:19 | <Ms2ger> | That's what it says, yes |
| 18:19 | <Ms2ger> | I've never found a source file |
| 18:20 | <annevk> | I guess you should ask smontagu |
| 18:20 | <Ms2ger> | Yeah |
| 18:20 | <smaug____> | that file was added to cvs 1999 |
| 18:21 | <Ms2ger> | smaug____, you don't have up-to-date contact details for ftang? :) |
| 18:21 | <zewt> | better contact Netscape Client International Team, then |
| 18:21 | <Ms2ger> | Well |
| 18:22 | <Ms2ger> | ftang may still be alive, I'm pretty sure NSIT isn't |
| 18:22 | <annevk> | it seems last time around you patched the source file Ms2ger |
| 18:23 | <annevk> | e.g. looking at the change log of http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvlatin/8859-13.ut |
| 18:23 | <Ms2ger> | Eh? |
| 18:24 | <smaug____> | haa, Ms2ger owns the file then ! |
| 18:24 | <Ms2ger> | In that case... |
| 18:24 | <Ms2ger> | Want to submit a patch to remove it? smaug____ claims I own it :) |
| 18:25 | <annevk> | see e.g. https://bug577945.bugzilla.mozilla.org/attachment.cgi?id=521559 |
| 18:25 | <annevk> | I cannot write the spec, the test, and the implementation |
| 18:25 | <annevk> | well I can |
| 18:25 | <annevk> | but I'm afraid of being called a monopoly |
| 18:25 | <smaug____> | Ms2ger has too many personalities, they can't keep up with what each others have been doing. :) |
| 18:26 | <annevk> | smaug____: sounds like http://thebjoernhoehrmannproject.org/ :p |
| 18:26 | <Ms2ger> | I know I changed the ut/uf files, yes |
| 18:27 | <zewt> | heh, the scripts in there refer to files that google's never even heard of ... except in the scripts |
| 18:27 | <zewt> | that's what happens when people make the mistake of committing generated files to version control |
| 18:28 | <smaug____> | and that is also an example what happens when commit message doesn't have bug number |
| 18:29 | <annevk> | I like how encodings are backed by probably four distinct implementations and how Google and Apple use ICU with different settings too, so maybe 4.5 |
| 18:29 | <zewt> | (... that = you lose the source file and everyone gives up and just starts modifying the output) |
| 18:29 | <bga> | var i = 10; while(i --> 0); |
| 18:30 | <annevk> | oh actually, iconv is ICU too I guess |
| 18:31 | <zewt> | i wonder how much microsoft's big CJK codepage tables have changed over the years |
| 18:45 | <timeless> | zewt: i think "sorting it all out" could tell you |
| 18:46 | <timeless> | http://blogs.msdn.com/b/michkap/ |
| 18:58 | <Velmont> | annevk: So, dented (and identi.ca will probably send it to twitter automatically soonish IIRC). |
| 19:31 | <Ms2ger> | annevk, any chance you could generate http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP864.TXT-style tables? :) |
| 19:32 | <zewt> | The requested URL /Public/MAPPINGS/VENDORS/MICSFT/PC/CP864.TXT-style was not found on this server. :P |
| 19:33 | <ojan> | what's the right spec to look at for figuring out the correct return values for getComputedStyle? |
| 19:34 | <ojan> | mdn claims to use used value from css2.1 |
| 19:34 | <Ms2ger> | cssom or -view |
| 19:34 | <ojan> | Ms2ger: ah, thanks |
| 19:35 | <zewt> | Ms2ger: you know you're looking at stuff from a prior era when a text file actually ends with a ^Z |
| 19:35 | <Ms2ger> | Well |
| 19:35 | <ojan> | Ms2ger. annevk: http://dev.w3.org/csswg/cssom/#resolved-value doesn't say what to do with shorthands |
| 19:35 | <Ms2ger> | That or the IETF is involved |
| 19:36 | <zewt> | that's what I said |
| 19:36 | <zewt> | (roundabout ietf burn) |
| 19:37 | <ojan> | annevk: also, "computed value" is not defined anywhere in the spec...presumably it needs to link to the appropriate CSS spec |
| 19:44 | <timeless> | heh |
| 19:45 | <timeless> | zewt: have you read sorting it all out? |
| 19:48 | <Ms2ger> | annevk, also, can you please update https://bitbucket.org/annevk/webencodings? |
| 19:54 | <timeless> | oh, zewt, if you're looking for disasters |
| 19:54 | <timeless> | i have one for you |
| 19:55 | <zewt> | timeless: havn't read much of it |
| 20:28 | <jgraham> | smaug____: I think it is generally accepted that we would like an open bug tracker but there are significant technical challenges |
| 20:32 | <Velmont> | We were joking about maybe getting it as the company provided xmas gift this year. <3 |
| 20:33 | <jgraham> | That would be even weirder than the year that everyone got a whole Norwegian salmon |
| 20:33 | <jgraham> | which had to be taken on the train to Sweden |
| 20:34 | <jgraham> | (this was long before I joined though) |
| 20:34 | <karlcow> | jgraham: was it alive? |
| 20:38 | <smaug____> | jgraham: is setting up a bugzilla really that difficult ;) |
| 20:39 | <karlcow> | smaug____: setting is never hard |
| 20:39 | <annevk> | Ms2ger: what do you want to have there? |
| 20:39 | <annevk> | ojan: I gave up on CSS |
| 20:39 | <timeless> | > For the record, I replaced the word he used with freaking there. He used 𝓕𝓾𝓬𝓴𝓲𝓷𝓰 only he didn't do something clever with Unicode to avoid the publish filters. |
| 20:39 | <karlcow> | fitting into a context and managing on a long term is always the issue. |
| 20:39 | <Ms2ger> | The things I fixed in Gecko last year |
| 20:39 | timeless | chuckles |
| 20:40 | <timeless> | Velmont: if you're in Norway, i think the best company gift would be butter :) |
| 20:40 | <annevk> | Ms2ger: okay |
| 20:40 | <annevk> | Ms2ger: for the Unicode-style tables, is it okay without the third column? |
| 20:41 | <annevk> | Ms2ger: and what is the use case? |
| 20:41 | <Velmont> | timeless: lol, Opera gave us loads of butter yesterday for the «risgraut» (rice porridge) we were having. |
| 20:41 | <Ms2ger> | smontagu pointed me at the tool that generates those tables |
| 20:41 | <Ms2ger> | And that's what they take |
| 20:41 | <jgraham> | smaug____: What karlcow said, mostly. The problem is more how to synchronise with our existing bugtracker which has some mix of stuff that anyone could know and internal-only stuff |
| 20:41 | <Ms2ger> | *it takes |
| 20:42 | <zewt> | jgraham: fork the "security bug" (hidden) flag to "private bug", and just set it to true for existing bugs? |
| 20:42 | <annevk> | Velmont: what's your twitter? |
| 20:42 | <jgraham> | The butter crisis is evidence that Sweden is ahead of Norway; we had that months ago |
| 20:42 | <Ms2ger> | I think leaving out the last column should work |
| 20:42 | <Ms2ger> | if(buf[0]=='0' && buf[1] == 'x') |
| 20:42 | <Ms2ger> | { |
| 20:42 | <Ms2ger> | sscanf(buf,"%hx %hx",&c,&u); |
| 20:43 | <zewt> | then they can be unhidden on a case-by-case basis and reporters can decide as they want for future bugs |
| 20:43 | <Velmont> | annevk: I'm Velmont on identi.ca and my ghosting twitter-account. |
| 20:43 | <timeless> | Velmont: sorry, it was just a hilarious news article to encounter |
| 20:43 | <jgraham> | zewt: Of course solutions exist but you know how it is, you need to decide waht works and then get lots of buy in |
| 20:43 | <annevk> | Ms2ger: I can also put #PLACEHOLDER there or some such if that is better |
| 20:43 | <timeless> | zewt: fwiw, bugzilla bug groups are a lot more than "security bug" |
| 20:43 | <annevk> | Ms2ger: rather not make things too fancy |
| 20:43 | <Ms2ger> | Yeah |
| 20:43 | <timeless> | it's trivial to make all old bugs "opera confidential" |
| 20:44 | <zewt> | timeless: yes, bugzilla is notoriously massively overcomplicated :P |
| 20:44 | <Ms2ger> | Having just 0xab 0xcdef should work, I think |
| 20:44 | <timeless> | and then let users file bugs as "public" (no group), "security" (security group), or "private" (another group) |
| 20:44 | <Ms2ger> | Or the "timeless" group, of course |
| 20:45 | <timeless> | Ms2ger: bugzilla has an Asa group |
| 20:45 | <zewt> | jgraham: but that's not a technical challenge at all, just a political one |
| 20:45 | <timeless> | err s/has/had/ |
| 20:45 | <jgraham> | Right, this is the sort of thing where it sounds like it ought to be easy in principle but in practice there are a lot of details that get in the way |
| 20:45 | <timeless> | getting security and private to work requires a bit of trickery, the easiest way is 3 public products: |
| 20:45 | <Ms2ger> | Well, you say "had", but how can I know that? :) |
| 20:45 | <timeless> | Normal |
| 20:45 | <timeless> | Security |
| 20:45 | <timeless> | Private |
| 20:45 | <timeless> | where the Security group has a mandatory mark for the security group |
| 20:45 | <timeless> | and similar for private |
| 20:46 | <timeless> | and normal users aren't in either group |
| 20:46 | <timeless> | then you allow the various products to have bugs from Opera-confi, and Security/Private |
| 20:46 | <timeless> | Ms2ger: i'm too lazy to check to see if the group is still present |
| 20:46 | <timeless> | remember that i have at times had editproducts/editgroupaccess controls |
| 20:46 | <timeless> | my favorite group was a group w/ 5 bugs |
| 20:54 | <timeless> | of course i can't actually look things up right now, mozilla.org is having issues |
| 20:54 | <Ms2ger> | Yeah, the PHX datacenter broke down |
| 20:57 | <annevk> | Ms2ger: should I just check them into dcvs? |
| 20:57 | <annevk> | I guess I will |
| 20:58 | <Ms2ger> | That works too |
| 20:58 | <annevk> | Ms2ger: http://dvcs.w3.org/hg/encoding/rev/3bf01afcf6e5 |
| 20:59 | <Ms2ger> | Thanks |
| 21:00 | <annevk> | I guess I should check my Python scripts in too at some point |
| 21:00 | <annevk> | maybe when I feel I can handle the embarrassment |
| 21:00 | <ojan> | annevk: oh right...forgot. someone else volunteered to take over cssom, right? |
| 21:01 | <annevk> | yes glenn and shane |
| 21:01 | <annevk> | I think |
| 21:01 | <annevk> | glenn asked a bunch of questions, but I'm not sure anything happened |
| 21:01 | <annevk> | your issue about computed style is probably already in http://lists.w3.org/Archives/Public/www-archive/2011Dec/0010.html |
| 21:01 | <annevk> | but I'm not sure if they will go through that |
| 21:06 | <Hixie> | sicking: when you argue that if people do things on the web it means they think it's the better thing... are you taking into account that they might not have any idea what they're doing? :-) |
| 21:06 | <sicking> | Hixie: sure, it's not a great argument |
| 21:06 | <sicking> | Hixie: but at least we can be informed by looking at how they used it |
| 21:07 | <sicking> | Hixie: i think saying that only functions is the better way of doing callbacks, you are saying that people shouldn't use object-oriented programming style |
| 21:07 | sicking | should point that out |
| 21:07 | <annevk> | Ms2ger: the problem with updating webencodings is that I don't have up to date information for Opera on Windows |
| 21:07 | <Velmont> | sicking: I fixed the status checked on state OPENED test problem, btw, so gecko's all green on it now. |
| 21:08 | <annevk> | Ms2ger: maybe I should just remove that and hope we get it straight at some point |
| 21:08 | <sicking> | Velmont: sweet |
| 21:09 | <TabAtkins> | sicking: No, that's a silly point. Object-oriented doesn't necessarily include using a JS Object. |
| 21:09 | <TabAtkins> | Using closures to encapsulate data in a function is OO as well. |
| 21:10 | <sicking> | TabAtkins: it functions, by wrapping your OO code in non-oo |
| 21:12 | <TabAtkins> | You have a pretty restricted view of what OO means. |
| 21:13 | <sicking> | TabAtkins: i know that I'm annoyed any time I have to do that when I'm writing code in C++ |
| 21:14 | <sicking> | TabAtkins: i.e. any time i'm interacting with c-style APIs that take a closure |
| 21:14 | <TabAtkins> | Sure, because C++ is really crappy for functional code, so using functional OO style is also really crappy. |
| 21:14 | <sicking> | i'm not sure what you mean by "functional OO" |
| 21:14 | <sicking> | i take it you don't mean functional in the sense of programming languages that don't modify state |
| 21:15 | <TabAtkins> | No, I mean in terms of functions being first-class objects. Sorry for these terms having multiple meaning. ;_; |
| 21:15 | <TabAtkins> | My point is that data-hiding with a Function object is just as OO as doing the same with an Object object. |
| 21:17 | <Ms2ger> | So, should we expose canvas' children when scripting is disabled? |
| 21:17 | <Ms2ger> | Philip`? :) |
| 21:18 | <TabAtkins> | That might make sense, yeah. |
| 21:20 | <Ms2ger> | Oh, the spec actually suggests that |
| 21:23 | <jgraham> | Oh the flamewar about programming styles failed to get going, I see. Probably all the rain making everything damp. |
| 21:23 | <Ms2ger> | Obviously python is the best language ever |
| 21:24 | <Ms2ger> | But only if written with emacs |
| 21:24 | <ojan> | sicking: i don't want to add more noise to that thread... |
| 21:24 | <sicking> | hang on, on phone |
| 21:24 | <ojan> | sicking: i guess i don't feel super strongly about this...we have bigger fish to fry wit the web platform |
| 21:25 | <ojan> | sicking: the whole thing just smells of useless bloat to me |
| 21:25 | <zewt> | do I even want to know |
| 21:27 | smaug____ | doesn't understand why "useless" |
| 21:27 | <smaug____> | callback objects are very handy in some cases |
| 21:27 | <smaug____> | that is why they are used as event listeners |
| 21:29 | <zewt> | anyone mind giving me some context here? |
| 21:29 | <TabAtkins> | Yes. |
| 21:30 | <zewt> | :| |
| 21:32 | <jgraham> | zewt: It's about things that can take either a function or an object {handleEvent:function(){}} |
| 21:32 | <zewt> | i've never really understood the purpose of that (the latter) |
| 21:32 | <jgraham> | There are people who want to allow more of the latter, but with different names |
| 21:32 | <zewt> | much cleaner to do eg. addEventListener("event", obj.func.bind(obj), false) |
| 21:32 | <jgraham> | depending on the type of thing |
| 21:32 | <zewt> | (which I do all the time) |
| 21:33 | <sicking> | i think we have different definitions of "cleaner" |
| 21:33 | <jgraham> | There are people who want to make both forms work everywhere just as stated |
| 21:33 | <zewt> | possible |
| 21:33 | <sicking> | obj.func.bind(obj) seems more messy than obj to me |
| 21:33 | <zewt> | it's nice how python basically does that for you, but doing the binding manually i've never found to be a big deal |
| 21:33 | <jgraham> | and there are people who want to pretend that the second form doesn't exist and stop adding new instances of it |
| 21:34 | <jgraham> | I think the binding thing is something that you have to live with in javascript |
| 21:34 | <zewt> | the only negative to binding manually in javascript is it makes unbinding harder (but that can be solved in other ways) |
| 21:34 | <zewt> | (removeEventListener, I mean) |
| 21:35 | <jgraham> | I don't think changing this one thing is going to make it so that people don't have to understand how binding works in general |
| 21:35 | <zewt> | sicking: i find passing in an object and having to know that some magically-named member function will be called to be fairly unpleasant, FWIW |
| 21:35 | <sicking> | zewt: so you don't like the UndoManager API then? |
| 21:36 | <zewt> | i havn't looked at it |
| 21:38 | <zewt> | jgraham: understanding how the bind() method works is something I consider basic, mandatory knowledge--maybe just because I use it so much to work around JS's crappy basic behavior for member functions, but just the same |
| 21:39 | <zewt> | (i think python's method binding is one of its greatest features--too bad that doesn't help us at all) |
| 21:39 | <smaug____> | zewt: how is anything "magically-named" ? |
| 21:39 | <smaug____> | it is defined in the API |
| 21:39 | <smaug____> | addEventListener is "magically-named" |
| 21:40 | <zewt> | if I call addEventListener(..., foo.func, false), it's very clear and immediate what's going to be called; much less so for passing in an object |
| 21:40 | <jgraham> | sicking: I think the design is way more defensible if you have a group of things that you have to pass together |
| 21:40 | <annevk> | Ms2ger: pushed an update to bitbucket |
| 21:40 | <zewt> | expanding that to other types of callbacks, with different names, would seem a very bad way forward (feels Ruby-ish) |
| 21:41 | <Ms2ger> | Thanks |
| 21:41 | <zewt> | (or Java-ish, if you like) |
| 21:41 | <annevk> | Ms2ger: I guess I should host the new table somewhere |
| 21:41 | <Ms2ger> | I'll have another look later |
| 21:41 | <sicking> | jgraham: which it would be if the functions had different names and you listened for several things, no? |
| 21:41 | <zewt> | jgraham: if it's a complex interface where you have to pass in a tightly-coupled set of callbacks, then yeah, I might buy that more |
| 21:42 | <annevk> | Ms2ger: I guess one more thing I can do is to make the spec definitions a "browser" |
| 21:42 | <annevk> | Ms2ger: for comparison purposes |
| 21:42 | <Ms2ger> | That would be nice, if it isn't too hard |
| 21:42 | <annevk> | shouldn't be in theory |
| 21:42 | <jgraham> | sicking: That isn't how it works in the event case though. And it isn't really clear why that would be a logical way to group things |
| 21:43 | <jgraham> | Maybe if the API was addEventListener({click:function(){}, mouseover:function(){}) etc. |
| 21:44 | <smaug____> | the object allows one to store state easily |
| 21:44 | <jgraham> | (and in that case we would probably want the whole jQuery-style delegates thing) |
| 21:44 | <jgraham> | smaug____: Well, state is evil ;) |
| 21:45 | <jgraham> | (but seriously, if you need to store state there is no difficulty) |
| 21:45 | <smaug____> | some states only :) |
| 21:46 | <Ms2ger> | Arizona? |
| 21:46 | <zewt> | while i don't buy into it *too* much, there's also something to be said for python's "only have one way to do things" philosophy--i don't see benefits to eg. handleEvent to offset splitting users down the middle and having everyone using basic APIs in two very different ways, in what seems mostly a style difference |
| 21:47 | <zewt> | (eat run-on sentence, IRC) |
| 21:47 | <zewt> | dashes are the new period |
| 21:52 | <zewt> | jgraham: in the blob reader callback api briefly discussed recently, i had suggested an interface like that, actually; it made sense there, since it was implementing an interface with several different tightly-related callbacks |
| 21:53 | <zewt> | since it was reduced down to one function I was going to suggest dropping that and just using a simple callback (don't think I bothered, since iirc we agreed the api probably wasn't worth it) |
| 22:18 | <annevk> | sweet I think I made it work |
| 22:25 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/single-octet-research.html |
| 22:25 | <Ms2ger> | Nice |
| 22:40 | <kennyluck> | I am curious again about how much difference there is between the Chromium and WebKit trunk regarding Web standards. This one didn't get into WebKit trunk it seems → http://code.google.com/p/chromium/issues/detail?id=69594 |
| 22:41 | <TabAtkins> | WebKit trunk is explicitly the Chromium trunk + a few things that are restricted by licenses/patents/etc. |
| 22:43 | <zewt> | seems rather odd for a bug to go "this is explicitly disallowed for security reasons" and then "okay, implemented anyway" |
| 22:43 | <zewt> | "???" |
| 22:43 | <zewt> | (havn't touched appcache myself so not going to dig at it) |
| 22:44 | <Hixie> | sicking: i don't see how passing an object that has a function is any more "object orientated" than passing a function whose closure has that object |
| 22:44 | <annevk> | zewt: the security concern already applied |
| 22:44 | <ap_> | kennyluck: Chromium has an separate private implementation of AppCache |
| 22:45 | <annevk> | zewt: to prevent the attack you need a header and that also prevents app cache |
| 22:45 | <sicking> | Hixie: so would you say that c-style structs are as object oriented as c++ classes? |
| 22:45 | <Hixie> | sicking: but in any case, while i think the "pass an object with a function" mechanism is pointless given that we have closures, i am not arguing against it. I'm just arguing against having lots of callbacks with lots of different names. |
| 22:45 | <zewt> | Hixie: (it's not at all) |
| 22:45 | <ap_> | kennyluck: https://bugs.webkit.org/show_bug.cgi?id=60571 tracks making this change for WebKit |
| 22:45 | <annevk> | hey ap_ |
| 22:46 | <ap_> | hey Anne |
| 22:46 | <Hixie> | sicking: a c-style struct containing a c++ class instance is as object-orientated as a c++ class instance containing a c-style struct, which would be the equivalent analogy |
| 22:46 | <zewt> | sicking: what do C or C++ have to do with it? neither has first-class functions or closures (well, ignoring insane new C++ stuff) |
| 22:46 | <kennyluck> | ap_, well then that contradicts what TabAtkins said then. |
| 22:46 | <kennyluck> | ap_, thanks for the link! |
| 22:46 | <annevk> | ap_: other reason for removing UTF-32 is reducing encoding proliferation and making it less likely for content to start depending on one user agent |
| 22:46 | <TabAtkins> | kennyluck: Believe ap_ |
| 22:46 | <sicking> | Hixie: the whole point is having functions on the object |
| 22:47 | <Hixie> | sicking: functions in JS _are_ objects. |
| 22:47 | <ap_> | annevk: I guess I'm a bit allergic to ideas about limiting encoding support, because it often means special cases and more work |
| 22:47 | <ap_> | annevk: UTF-32 is not really one of those cases |
| 22:47 | <zewt> | as far as i'm concerned, the idea of passing an object containing a function when you really want to say "call this function" is just a nasty echo of java Runnable |
| 22:47 | <ap_> | annevk: text formats that HTML5 limits to UTF-8 definitely is more work for questionable benefit (at best) |
| 22:48 | <annevk> | ap_: guess that depends on the implementation, I can see how it's true for ICU |
| 22:48 | <sicking> | Hixie: i don't see how that's relevant |
| 22:48 | <sicking> | Hixie: no-one is arguing that you can't do this with only function callbacks |
| 22:48 | <sicking> | Hixie: it's a question of developer ergonomics |
| 22:48 | <Hixie> | sicking: instead of var o = { handleEvent: function () { ... }, state: 0 }; callback(o); you can just do var f = function () { ... }; f.state = 0; callback(f); |
| 22:48 | <smaug____> | zewt: it is not about "call this function". It is about call the function of this object. |
| 22:49 | <sicking> | Hixie: indeed. Objects are totally unneccesary |
| 22:49 | <Hixie> | sicking: anyway my argument isn't against objects. my argument is against having the callbacks have different names from each other. |
| 22:49 | <sicking> | Hixie: basic is just as turing complete as C++ and Java |
| 22:50 | <TabAtkins> | I don't understand what imaginary position you're attempting to argue against, sicking. |
| 22:51 | <sicking> | TabAtkins: the question is what programming syntaxes we want to support |
| 22:51 | <smaug____> | is sicking arguing against something? |
| 22:51 | <TabAtkins> | sicking: I understand that. I'm wondering why the word "BASIC" got into the argument. |
| 22:51 | <smaug____> | I thought he is arguing why object callbacks are a nice feature |
| 22:51 | <zewt> | smaug____: it's "do this thing"; passing in a function (possibly created via function.bind) is much more direct than passing in an object containing a method to do the thing |
| 22:51 | <TabAtkins> | I suspect you're badly trying to make a reductio ad absurdum |
| 22:51 | <sicking> | TabAtkins: basic doesn't have objects |
| 22:52 | <sicking> | TabAtkins: well.. it didn't used to |
| 22:52 | <smaug____> | zewt: how is that "much more direct" ? |
| 22:52 | <zewt> | how is it not? |
| 22:52 | <zewt> | "here's the thing. do it" |
| 22:52 | <sicking> | look at how people like google, facebook, jquery etc write their code. There's tons of objects and "classes" |
| 22:53 | <smaug____> | "here is the callback object, use it" |
| 22:53 | <sicking> | anyhow, i'd rather argue on the mailing list than here |
| 22:53 | <sicking> | to allow broader participation |
| 22:53 | <Hixie> | you haven't argued here at all :-) |
| 22:53 | <Hixie> | at least, not against the point i was making |
| 22:53 | <zewt> | smaug____: no, it's "here's the object, call the function with the implicit name XXX on it" |
| 22:53 | <sicking> | Hixie: then you're not understanding my argument |
| 22:54 | <zewt> | i think a lot of us aren't :) |
| 22:54 | <Hixie> | sicking: of that i am sure |
| 22:54 | <smaug____> | I certainly can't understand Hixie's argument why handleEvent should be the method name everywhere. |
| 22:55 | <annevk> | what is wrong with that? |
| 22:55 | <zewt> | the only argument I've seen for eg. handleEvent instead of passing a function is so you don't have to tack ".bind(obj)" on the end of the object (which seems trivial to me) |
| 22:55 | <zewt> | er, end of the function name |
| 22:56 | <zewt> | (actually, I often just pre-bind my functions, eg. this.mousemove = this.mousemove.bind(this), all in one block in the ctor) |
| 22:56 | <smaug____> | annevk: if you're not handling any kind of "event", why the function name should be handleEvent? Also, different handleEvent functions would need to handle different kinds of parameters |
| 22:56 | <annevk> | you always handle some kind of "event" |
| 22:56 | <annevk> | in the broad sense of "event" |
| 22:57 | <Hixie> | smaug____: i've given several reasons. to summarise: authors would have to remember the names if it wasn't consistent, and can't rely on autocomplete in IDEs to do it for them, nor would it be easy to look up in documentation. Having multiple names would make using objects to do generic proxies harder as you've have to pass the callback name. Having different names would mean migrating from function-style to object-style in an environment that used proxies would me |
| 22:57 | <smaug____> | in the broad sense yes, but not in web api sense, I'd say |
| 22:57 | <annevk> | that's what a callback is after all |
| 22:57 | <annevk> | an event |
| 22:57 | <smaug____> | where else in web apis is "event" use than in dom events |
| 22:57 | <zewt> | smaug____: my question is: if handleEvent is to be used for things other than DOM events (for legacy compatibility): why should it be used instead of (or in addition to) the API accepting a function? what's the benefit, weighed against complicating the API and adding avoidable style variances? |
| 22:58 | <Hixie> | smaug____: [...] would mean migrating from function-style to object-style in an environment that used proxies would mean changing all the call sites as well. And finally, the main reason put forward for having different names -- being able to use one object for multiple callbacks -- is unrealistic as in practice you'd likely be needing multiple functions for the same callback type, not different callback types. |
| 22:59 | <heycam> | Hixie, at least if you are handling the same callback type it means you have the same argument list passed in -- and with DOM Events you can switch based on event.target/type |
| 22:59 | <smaug____> | zewt: consistency with event listeners, and also, apparently developers like callback objects, since it is used quite often |
| 22:59 | <heycam> | if you have different callback types handled by the same function, that's going to be impossible |
| 23:00 | <Hixie> | heycam: if you're doing a proxy thing that just e.g. counts accesses, you'd just be forwarding all the arguments to the "real" handler |
| 23:00 | <Hixie> | heycam: so it doesn't matter what the arguments are |
| 23:01 | <zewt> | smaug____: 1: event listeners do this (from my perspective) for legacy compatibility; "consistency with legacy APIs" is not interesting (if this was taken as an argument, it would lead to very, very ugly APIs); 2: but I'd like to know *why* they like it, what the rational reason for doing/supporting this is |
| 23:01 | <heycam> | Hixie, I think that is not nearly going to be the common case, where you want the same function to handle all different kinds of callbacks |
| 23:01 | <Hixie> | heycam: using this at all is not going to be the common case |
| 23:03 | <heycam> | Hixie, my argument is that if you are going to support the object style, and one of the reasons being so that you can have a single object with state, that you should have different names otherwise its usefulness is diminished |
| 23:03 | <Hixie> | heycam: being able to dispatch based on the argument is a rarity -- only applies to DOM Event callbacks |
| 23:04 | <Hixie> | heycam: so i argue that having different names does basically nothing to help with that |
| 23:04 | <Hixie> | heycam: e.g. if i have many canvases and i call toBlob() on lots of them -- can't use the same object |
| 23:04 | <smaug____> | zewt: I would assume people like callback objects since it allows developer to encapsulate the needed functions and properties to an object easily |
| 23:04 | <zewt> | but you can do that with functions very easily too |
| 23:04 | <Hixie> | heycam: or if i use DataTransferItem's getAsString() on lots of DataTransferItems, can't use the same callback object |
| 23:04 | <smaug____> | zewt: you need bind explicitly |
| 23:04 | <zewt> | big deal |
| 23:04 | <smaug____> | need to |
| 23:05 | <Hixie> | heycam: JS functions can have state, so you don't need to use the object style to have a single object with state |
| 23:05 | <zewt> | one line of code per function, at most |
| 23:05 | <heycam> | Hixie, can't because of the semantics of your application? and because they don't pass an argument identifying the canvas/transferitem? |
| 23:05 | <smaug____> | zewt: it is, if you have simpler way to do it |
| 23:05 | <Hixie> | heycam: can't because there's no context in the argumentsl ist |
| 23:05 | <zewt> | this is not simpler, it's making the whole API more complex by having multiple ways to do things (which now everyone has to know) |
| 23:05 | <zewt> | that's not even in the ballpark of being worth it, for eliminating "this.func = this.func.bind(this)" |
| 23:07 | <heycam> | Hixie, I think that is a reasonable point. with DOM Events it is easy to have the one handleEvent function handle different sources of the event. but with other callback APIs we have, that is not possible. |
| 23:07 | <heycam> | Hixie, so we already have some limitation in the set of handlers you can put on a single object because of that |
| 23:08 | <zewt> | also that doesn't help with events at all (since events all use the same callback name), so it doesn't seem to explain why people use it |
| 23:08 | <smaug____> | (there is a reason why mutationobserver callback has mutationobserver as a parameter) |
| 23:08 | <heycam> | Hixie, and you have to be "lucky" that you want to handle either only a single source per callback method name |
| 23:08 | <heycam> | s/either// |
| 23:09 | <Hixie> | heycam: i have yet to see a single realistic example of a time where you would be so lucky. all the cases i've looked at are cases where you'd be using multiple callbacks of the same type. |
| 23:09 | <Hixie> | heycam: (e.g. DOM Events, toBlob(), etc) |
| 23:12 | <heycam> | Hixie, yeah so I'm saying that with DOM Events (and apparently as smaug____ says with mutation observers) you get a parameter that lets you differentiate the source of the callback |
| 23:12 | <heycam> | I would say then that to avoid this problem of using the same callback method for different sources, all these other callback APIs signatures should grow an argument to indicate the source |
| 23:12 | <Hixie> | heycam: and i'm arguing that this means that the argument saying that we need different names so one object can be used with different callback types is too weak to consider, especially against all the other points raised against having multiple names. |
| 23:12 | <heycam> | (if you did indeed want to ensure that your single object can handle all kinds of different sources and callback types) |
| 23:12 | <zewt> | heycam: i've never found that to be a problem in practice (not one worth bloating every callback API for, certainly) |
| 23:12 | <Hixie> | i'm not convinced it's an interesting use case. just use closures. |
| 23:12 | <heycam> | Hixie, I would agree it is weaker. (weak enough? not sure. maybe.) |
| 23:14 | <zewt> | is "calling bind() is sort of annoying" the only argument? |
| 23:14 | <zewt> | or did I miss others |
| 23:15 | <heycam> | zewt, let's say you have a single object with multiple callback methods on it. you at least have to duplicate the method names on each callback registration function call, too. |
| 23:15 | <heycam> | so intead of addEventListener(type, obj, false) you need to do addEventlistener(type, obj.functionname.bind(obj), false) |
| 23:16 | <zewt> | heycam: let's back up a step, you're talking about two separate things there |
| 23:16 | <heycam> | (not saying that is strong, just pointing out it's not only ".bind()") |
| 23:16 | <zewt> | 1: having to say obj.functionname instead of obj, and 2: having to tack on bind(obj) |
| 23:16 | <heycam> | zewt, it's the same thing. you need both, right? :) |
| 23:16 | <zewt> | 1: i think is perfectly fine and a good API, in a language with first-class functions |
| 23:16 | <Hixie> | it is unrealistic to expect that someone will magically have a perfect mapping of types of callbacks to actuall callback functions |
| 23:16 | <Hixie> | even if one did use objects one would _still_ have to pick the right callback |
| 23:17 | <zewt> | i mean, i think foo(obj.functionName) is a much much cleaner, more obvious API than foo(obj) where "functionName" is baked into the API, at least when there's only one callback involved |
| 23:17 | <heycam> | Hixie, "pick the right callback"? didn't quite follow that. |
| 23:17 | <Hixie> | e.g. addEventListener('load', callbackObjects.myLoadCallbackObject); addEventListener('click', callbackObjects.myClickCallbackObject); |
| 23:17 | <zewt> | 2: bind(obj)--yeah it's "sort of annoying" but that's about it |
| 23:19 | <heycam> | Hixie, it is true you would still need to switch based on say the .type of the event object |
| 23:20 | <heycam> | Hixie, (though you could do that in your handleEvent pretty simply by looking up a property based on the type, and calling that function if it exists.) |
| 23:20 | <annevk> | heycam: https://bugs.webkit.org/show_bug.cgi?id=74648 |
| 23:20 | <annevk> | heycam: would prolly be good to decide on "|" or "or" |
| 23:20 | <heycam> | zewt, I think the clarity is a good point, where you don't have the functionName listed in your registration function call so it is less obvious exactly what is going to get called |
| 23:20 | <zewt> | i don't think this.handleEvent = function(e) { switch(e.type) { case "load": this.onLoad(); break; case "click": this.onClick(); } } is a win over a couple bind() calls :) |
| 23:21 | <annevk> | heycam: oh, and define unions :) |
| 23:21 | <Hixie> | you're arguing that encouraging a style where all event handling goes through one method that dispatches on target and type is better than encouraging a style where the browser just sends the event to the right code itself? |
| 23:21 | <heycam> | annevk, don't you mean we have to decide whether to include unions or not first? :) |
| 23:21 | <heycam> | annevk, I'm going to have to treat unions, overrides, [AllowAny] all at once |
| 23:21 | <heycam> | since they all interrelate |
| 23:21 | <zewt> | (unions? in javascript? whaaaat) |
| 23:21 | <annevk> | heycam: yeah |
| 23:22 | <heycam> | Hixie, I am not arguing that. I am just saying there that it doesn't matter so much that all DOM Events are smushed into the one handleEvent, because you can easily discriminate based on type/target and dispatch to the specific handler function based on that. |
| 23:23 | <zewt> | http://zewt.org/curves/draggable.js i do this a lot; it's a little annoying to have to, but none of this is better |
| 23:23 | <annevk> | zewt: in IDL so not every function will implement its own rudimentary argument checks |
| 23:23 | <zewt> | annevk: hmm |
| 23:23 | <Hixie> | heycam: I am saying that it is terrible if all DOM Events are smushed into one method, because you have to discriminate based on type/target and dispatch to the specific handler function based on that. |
| 23:24 | <Hixie> | heycam: instead of just registering them in the first place and not having to do any of that work at event handling time. |
| 23:24 | <Hixie> | heycam: seems like a pretty strong example of why you would not want to use an object here |
| 23:24 | <annevk> | obviously you would use one object per event type |
| 23:25 | <smaug____> | AFAIK, it is pretty common to have an object with handleEvent to handle different event types and event targets |
| 23:25 | <heycam> | Hixie, the reason you use an object is to get simple access to your state shared across multiple handlers |
| 23:26 | <Hixie> | heycam: the reason you use a closure is to get simple access to your state shared across multiple handlers too |
| 23:26 | <zewt> | ... but that's what objects are for (and we've looped the conversation) |
| 23:27 | <zewt> | (er, what hixie said, of course) |
| 23:27 | <zewt> | i mean using bind() gives you an object to share state on in exactly the same way |
| 23:27 | <heycam> | so that comes back to zewt's question from before |
| 23:27 | <annevk> | Velmont: heh, just noticed you reused some of the code of my tests |
| 23:27 | <Hixie> | you don't need bind() even |
| 23:28 | <heycam> | about whether avoiding bind() is the real difference |
| 23:28 | <heycam> | Hixie, sure |
| 23:28 | <Hixie> | just have the state in scope |
| 23:28 | <heycam> | Hixie, just closed over variables |
| 23:28 | <heycam> | right |
| 23:28 | <zewt> | Hixie: that's just a stylistic difference |
| 23:28 | <zewt> | but yes |
| 23:28 | <annevk> | Velmont: HTTP status "699 WAY OUTTA RANGE" :) |
| 23:28 | <zewt> | both ways work |
| 23:28 | <Hixie> | zewt: the whole discussion is about stylistic differences |
| 23:28 | <Hixie> | zewt: all of these ways work |
| 23:28 | <heycam> | yes |
| 23:28 | <zewt> | i don't like writing large blocks of code as closures; i prefer member functions |
| 23:28 | <heycam> | I think that's why I dislike this issue, it's pretty much only style :) |
| 23:28 | <heycam> | in fact that's most of the difficult to resolve web idl issues :/ |
| 23:29 | <Hixie> | i'm not arguing that we shouldn't allow authors to use objects (though i certainly wouldn't be sad if we only allowed functions) |
| 23:29 | <Hixie> | i'm just saying that if we do allow objects, we should make them consistent so you know it's always handleEvent() |
| 23:29 | <Hixie> | and don't have to look it up each time |
| 23:29 | <heycam> | Hixie, I am arguing that we shouldn't allow authors to use objects if we use the same name, since it makes them less useful. (but I did say that before.) |
| 23:29 | <zewt> | i'd argue that the handleEvent thing shouldn't be propagated to new APIs |
| 23:29 | <Hixie> | and don't have to pass the method name around when you're making proxies |
| 23:29 | <Hixie> | heycam: i'd be fine with that too |
| 23:29 | <heycam> | Hixie, and not only less useful, but definitely not useful enough to support |
| 23:29 | <zewt> | (i mean, APIs other than DOM event listeners) |
| 23:30 | <Hixie> | heycam: i'm not sure the object style is useful enough to support at all, modulo compat needs |
| 23:30 | <heycam> | (btw I did mention on the list previously that I am mostly on the side of "only allow functions", but I am interested in teasing out the arguments here) |
| 23:30 | <smaug____> | consistency in APIs is important |
| 23:30 | <zewt> | the entire handleEvent thing feels like an API designed by a Java programmer, who's only ever used java Runnable objects and didn't understand first-class functiosn at all |
| 23:30 | <Hixie> | heycam: but if we did have it, i think it'd be more useful to have them all the same name than have different names |
| 23:31 | <Hixie> | zewt: it _is_ a java thing |
| 23:31 | <Hixie> | zewt: the DOM was originally designed for Java |
| 23:31 | <zewt> | i try to avoid actually knowing about java things; it's one of the worst, most painful languages I've ever spent time in |
| 23:31 | <heycam> | is that true? or is it just that it was designed with OMG IDL which doesn't allow non-Java-like interfaces to be designed? |
| 23:31 | <zewt> | my conclusion is always: Java Hates Programmers, And Wants To Hurt You |
| 23:34 | <Hixie> | heycam: as far as i can tell, it was designed for Java implementations, with JS as a secondary concern. |
| 23:34 | <Hixie> | heycam: or at least, was designed to have Java as at least as important a concern as JS |
| 23:44 | <smaug____> | class attribute uses space separated class names |
| 23:44 | <smaug____> | in which case are some names separated using , ? |
| 23:47 | <smaug____> | nm, found |
| 23:47 | <Hixie> | smaug____: <input accept> <input type=email multiple value>, <meta name=keywords content> |
| 23:48 | <Hixie> | i think that's it |
| 23:48 | <Hixie> | <area coords> maybe also |
| 23:49 | <smaug____> | I was just thinking to change allowfullscreen to allow="fullscreen pointerlock" |
| 23:49 | <smaug____> | and whether it should use space or comma |
| 23:49 | <smaug____> | not that it matters much |
| 23:49 | <smaug____> | but apparently space is used more often |
| 23:50 | <Hixie> | definitely space |
| 23:50 | <Hixie> | and yeah, that would make much more sense than allowfullscreen allowpointerlock |
| 23:50 | <Hixie> | and would go well with the sandbox="" attribute |
| 23:52 | <smaug____> | annevk: ^^ |
| 23:54 | <annevk> | wfm |
| 23:57 | <zewt> | i sure wish the whole "your download will start in *pointless delay*" would die |