07:28 | <zcorpan> | "Table having datatable="0" attribute is layout table (Firefox 10)" http://asurkov.blogspot.com/2011/10/data-vs-layout-table.html |
07:30 | <hsivonen> | zcorpan: I tried to comment to ask what that was about, but the commenting system didn't work in Firefox |
07:31 | <hsivonen> | oh, now there are additional comments explaining that it's a JAWSism |
07:31 | <hsivonen> | sigh |
07:37 | <hsivonen> | I was able to comment using Opera |
07:38 | <hsivonen> | could be due to Blogger sniffing problems with Firefox 10 |
07:38 | <hsivonen> | or I have some privacy settings in Firefox that Blogger doesn't like |
08:33 | <foolip> | annevk, doesn't http://jsconsole.com/ and http://software.hixie.ch/utilities/js/live-dom-viewer/ have the same issue? |
08:34 | <zcorpan> | foolip: yes |
08:34 | <zcorpan> | foolip: but they don't have a blog in the same origin |
08:35 | <zcorpan> | foolip: so i can XSS your blog |
08:35 | <foolip> | zcorpan, my blog is at blog.foolip.org, but I guess that doesn't help for cookies? |
08:35 | <zcorpan> | oh, i thought it was at foolip.org |
08:39 | <zcorpan> | foolip: btw, your viewer loses styles when going back/forward in opera |
08:39 | <foolip> | zcorpan, yeah, I've seen that, but don't understand why |
08:55 | <foolip> | nessy1, <data> isn't relevant to http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change |
08:56 | <foolip> | and neither are data-* attributes if the point is to forward information to a plugin architecture |
08:57 | <zcorpan> | foolip: the textarea has class "processed" when it's rendered correctly |
08:57 | <zcorpan> | foolip: and no class after navigation |
08:59 | <foolip> | zcorpan, the side-effects make it seem like scripts aren't re-run on navigation, or that the previous state is not kept, whichever it is we do when navigating history |
09:01 | <zcorpan> | foolip: in your case i think we do a bfcache navigation, so scripts aren't rerun. but i don't know why the state isn't kept |
09:02 | <foolip> | I'll file a site compat bug |
09:02 | <zcorpan> | so both :) |
10:36 | <foolip> | Hixie, what's the vocabs-index file in the spec source? It's out of sync, at least. |
12:12 | <hsivonen> | Can someone remind me what the latest thinking on data: URL origin inherince is? |
12:13 | <hsivonen> | Does a doc loaded from a data: URL have a unique origin or the origin of the document that created the data: URL? |
13:12 | <smaug____> | Ms2ger: is moznet down? (or is it just me who has problems to connect to that irc server) |
13:12 | <Ms2ger> | gravel.m.o wfm |
13:20 | <smaug____> | ping irc.mozilla.org |
13:20 | <smaug____> | ping: unknown host irc.mozilla.org |
13:25 | <plutoniix> | smaug____, dns problem ?- - |
13:25 | <smaug____> | could be |
13:25 | <smaug____> | but works now |
13:40 | <bga_> | hm |
13:40 | <bga_> | is it possible to style <area>? |
14:04 | <annevk> | via dino: http://www.youtube.com/watch?v=0Z09bNgSeMI |
14:04 | <annevk> | seems like something I have to watch |
14:16 | <annevk> | hsivonen, origin of the document that created it |
14:21 | <hsivonen> | annevk: thanks. And WebKit hasn't fixed that yet? |
14:23 | <annevk> | hsivonen, correct |
14:23 | <hsivonen> | ok |
15:32 | foolip | must be out of touch with reality, seeing all the shock and outrage over the end of <time> |
15:32 | <Ms2ger> | I see what you did there |
15:33 | <J_Voracek> | Nice ;-) |
15:37 | <zcorpan> | yeah i don't understand why the fuzz |
15:37 | <foolip> | Is it only inside this echo chamber that it seems to make sense, and in that case why? |
15:37 | <Ms2ger> | Because a spec in LC must be "STABLE" |
15:38 | <foolip> | Actually, I haven't seen anyone pulling the "stop changing things at random" argument |
15:38 | <foolip> | More "but it's so useful, I use it all the <time>!" |
15:38 | <Ms2ger> | I saw shelly make that argument |
15:40 | <foolip> | So maybe I missed that, in any case most people seem to be upset about the substance of the change rather than the fact that a change happened |
15:42 | <bga_> | http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/ |
15:43 | <zcorpan> | brucel argued that <data value> can't be validated. it can, of course, but it moves from the html layer validation to the microdata vocab layer validation |
15:44 | <zcorpan> | i guess i should comment on his blog |
15:45 | <miketaylr> | http://twitter.com/#!/LeaVerou/status/130837370185580545 |
15:46 | miketaylr | shrugs |
15:48 | <zcorpan> | i agree with brucel's point though that data-* and <data> are for different uses is confusing |
15:49 | <zcorpan> | is there a need for an element at all? can it be a global itemvalue="" instead? |
15:49 | <zcorpan> | microformats can't use that, but they refused to use <time> anyway, so anything we introduce for microformats won't be used by microformats according to the track record |
15:52 | <zcorpan> | maybe itemvalue="" would be confusing on <a>, <object> etc |
15:53 | <miketaylr> | zcorpan: i don't think this sentence is going to help alleviate confusion between <data> and data-*: "The element can also, however, be used in conjunction with scripts in the page, for when a script has store a literal value alongside a human-readable value. In such cases, the format to be used depends only on the needs of the script. (The data-* attributes can also be useful in such situations.)" |
15:59 | <foolip> | miketaylr, file a bug? |
15:59 | <miketaylr> | foolip: can do. already filed one on the typo. |
16:01 | miketaylr | filed |
16:04 | <Hixie> | foolip: it's historical |
16:04 | <foolip> | mkay, otherwise I'd have told you that you left <time> in it |
16:05 | <Hixie> | i should probably remove it |
16:06 | <Hixie> | there, it's gone |
16:41 | <Ms2ger> | "Alex: Let's make floats work." |
16:41 | <Ms2ger> | Hear, hear |
16:42 | <gsnedders> | heheheh. |
16:42 | <gsnedders> | Oh Alex… |
16:42 | <gsnedders> | (Mogilevsky, I presume?) |
16:43 | <Ms2ger> | Yep |
16:57 | <Ms2ger> | "arronei: Next is insect-rect." |
17:42 | <myakura> | http://www.w3.org/2011/11/TPAC/live/ "W3C's serving capacity for various XML schemata (.dtd, .mod, .ent, .xsd) is exceeded at present." |
17:44 | <Ms2ger> | Let's get rid of them! |
17:46 | <AryehGregor> | It's what, less than a hundred files? You should be able to serve ten thousand requests per second from one machine if it's configured properly and doesn't have terrible hardware. |
17:47 | <AryehGregor> | Periods of sustained bandwidth usage of 350 Mbps is going to be kind of expensive, but mostly just for the bandwidth. |
17:47 | wilhelm | holds down F5. That probably helps. |
17:48 | <AryehGregor> | Server-wise, you'd need only a handful of boxes running Varnish or Squid. |
17:51 | <Philip`> | Won't you tend to run out of things like port numbers if you have tens of thousands of requests on a single machine? |
17:53 | <Philip`> | (Apache seems to have problems with even dozens of requests per second, so I've used Squid on some site for that, but haven't had to worry about really high traffic) |
17:54 | <zewt> | Philip`: not going to run out of remote port/remote ip pairs |
17:55 | <Hixie> | how many browsers have <details> now? is it worth adding an event for when it opens yet? |
17:56 | <Hixie> | do we have an event that would be suitable for that? |
17:56 | <Hixie> | i'm thinking onchange, but it bubbles normally which seems bad for this kind of thing |
18:03 | <annevk> | wtf |
18:03 | <annevk> | there's like >200 people in the room |
18:03 | <annevk> | TabAtkins just blamed me |
18:03 | myakura | thinks better no to go.. |
18:04 | <karlcow> | annevk: more like 20,000. |
18:04 | <annevk> | over 9000! |
18:04 | <jgraham> | Hixie: I thought just webkit, but lst I saw the implementation was horrible |
18:04 | <karlcow> | ;) |
18:04 | <paul_irish> | Hixie: why would a bubble be bad for details onchange? |
18:05 | <smaug____> | paul_irish: because change event has been traditionally used for other things |
18:05 | <paul_irish> | aye |
18:05 | <paul_irish> | event.target.nodeName wasssupppp |
18:05 | <jgraham> | onchange seems like a horrible event to use |
18:06 | hober | says hi to jgraham from the next seat |
18:06 | <paul_irish> | i would mostly agree with that part. the bubbling i'd want though |
18:06 | <smaug____> | ontoggle or some such would be better, I think |
18:07 | <jgraham> | Right, that seems like a better name and less chance of conflict with existing code |
18:08 | <myakura> | Hixie: AFAIK, WebKit has some support but Safari preffed it off, so Chrome is the only browser which currently supports <details> |
18:11 | <jernoble> | Hixie: MediaController question for you: is the "most recently reported readiness state" intentionally left out of the IDL for MediaController? Same Q for the "playback state". |
18:12 | <karlcow> | http://www.cloudfour.com/device-detection-as-the-future-friendly-img-option/ |
18:12 | <jernoble> | Hixie: it just seems weird to me that you can't ask a MediaController what it's playbackState is. |
18:19 | <slightlyoff> | why is bubbling bad for that? |
18:19 | <slightlyoff> | bubbling is nearly always good |
18:31 | <Hixie> | paul_irish: because otherwise if you nest them, it would be hard to use an onfoo="" event handler on the outer one |
18:31 | <Hixie> | paul_irish: (or indeed if you put any form controls in it, if we reuse change) |
18:31 | <Hixie> | myakura: k, thanks |
18:32 | <Hixie> | jernoble: how do you mean? |
18:32 | <jernoble> | Hixie: so, i'm in the middle of doing a first-pass implementation of MediaController in WebKit |
18:32 | <jernoble> | Hixie: and so i'm writing some test cases to double check my implementation |
18:33 | <jernoble> | Hixie: and i realize halfway through that I have no way of testing, from within a running page, what the ready state of a given MediaController is |
18:33 | <Hixie> | hm, good point |
18:33 | <Hixie> | i guess you can work it out pretty easily |
18:33 | <Hixie> | it's just the lowest value of all the slaves, right? |
18:33 | <jernoble> | Hixie: sure, you could do the same work in the script as you do in the UA. |
18:34 | <jernoble> | Hixie: but the UA has to calculate it anyway, and it would be very simple for me to wire up a new accessor for that pre-calculated value |
18:34 | <Hixie> | that's probably why it's not exposed -- i just needed to calculate it to expose the events, not for the IDL |
18:34 | <Hixie> | but if there's a use case for it, we can add it to the IDL |
18:35 | <Hixie> | send mail describing the use case :-) |
18:35 | <jernoble> | Hixie: sure thing. :) |
19:11 | <Hixie> | if anyone wants to play openttd with us, btw, we have a server running -- server name is TPAC, /msg me for the password |
19:11 | <Hixie> | we'll be running it all week |
19:33 | <TabAtkins_> | Ms2ger, annevk: Is there anything fundamentally wrong with a DOM event firing on an element that's no longer in the DOM (but not deleted, just removed)? |
19:34 | <TabAtkins_> | Specifically in the context of animationEnded events. |
19:34 | <Ms2ger> | Not in a document? No |
19:34 | <TabAtkins_> | Nothing wrong? |
19:35 | <Ms2ger> | Don't think so |
19:35 | <TabAtkins_> | kk |
19:37 | <TabAtkins_> | smaug____: Any second opinions? (The CSSWG is just wanting to make sure.) |
19:39 | <zewt> | DOM events are used on things that aren't nodes at all, anyway |
19:40 | <zewt> | i'd think lots of events would already be received on nodes already in that case, if you remove the node when the task is already queued, but maybe they're cleared somehow |
20:34 | <AryehGregor> | TabAtkins, I'm pretty sure all kinds of events already fire on nodes that don't descend from a Document. |
20:35 | <AryehGregor> | Like what if you do var audio = new Audio(url); audio.play()? |
20:35 | <annevk> | yes events can fire whenever |
20:35 | <AryehGregor> | Mutation events presumably fire on such nodes too. |
20:38 | <AryehGregor> | "Microsoft Corp. has joined the HTML Editing APIs Community Group" |
20:38 | <AryehGregor> | Awesome! |
20:39 | AryehGregor | does a little dance |
20:56 | <dglazkov> | yay AryehGregor |
21:06 | <MikeSmith> | AryehGregor: booyah |
21:08 | <hober> | word |
21:10 | <slightlyoff> | hooray |
21:11 | <jgraham> | Hmm, using getOwnPropertyDescriptor on native objects seems to be problematic. Or I am doing something wrong? |
21:11 | <slightlyoff> | on host objects? |
21:11 | <jgraham> | Yeah |
21:12 | <jgraham> | One day I will get those terms the right way around |
21:12 | slightlyoff | checks the spec |
21:15 | <jgraham> | Hmm, seems to work OK in some cases. It's probably more of a WebIDL compliance problem |
21:17 | <jgraham> | (alternate point of view: WebIDL is a lie) |
21:17 | <Ms2ger> | All specs are cake |
21:17 | <heycam> | mmmm spec cake |
21:17 | <dglazkov> | Can someone throw something at Ms2ger so that I can identify him in the room? |
21:17 | Ms2ger | waves at dglazkov |
21:18 | <dglazkov> | Ms2ger: ah, so you're not in the room :) |
21:18 | <Ms2ger> | Indeed |
21:19 | <slightlyoff> | so these things should be able to return property descriptors |
21:19 | <slightlyoff> | they're required to have semantics for all of the [[]] opeations |
21:19 | <jgraham> | slightlyoff: Yup |
21:19 | <slightlyoff> | implementation bug |
21:20 | <jgraham> | It seems like I was being unreasoably optimistic about how closely anyone followed the inheritance/accessor property requirements in WebIDL |
21:20 | <heycam> | :) |
21:21 | <dglazkov> | slightlyoff: where are you? |
21:22 | <slightlyoff> | webapps |
21:29 | <gsnedders> | jgraham: Does ES5 guarantee that getOwnPropertyDescriptor will work on a host-object? I think not. The intention of WebIDL is that it should, though. |
21:30 | <jgraham> | gsnedders: Dunno |
21:32 | <dglazkov> | This TPAC thing is highway robbery. I came to see famous people. And they don't even have Ms2ger! |
21:32 | <Ms2ger> | Hah |
21:33 | <Scorchin> | dglazkov: What's TPAC? |
21:33 | Scorchin | wants it to be a 2pac conference |
21:33 | <gsnedders> | What's Ms2ger? Is it a person? |
21:33 | <dglazkov> | it's a week-long celebration of Tupac Shakur |
21:33 | <Scorchin> | 8D |
21:33 | <Philip`> | I'm not sure that Ms2ger actually has a corporeal existence |
21:33 | <dglazkov> | that's disappointing |
21:34 | <gsnedders> | Nor am I. |
21:35 | <Scorchin> | "... brings together W3C Working, Interest, and Incubator Groups, the Advisory Board, the TAG and the Advisory Committee for an exciting week of coordinated work" |
21:38 | <hober> | Scorchin: well, it is Halloween, so 2pac and t-pain costumes are preferred. |
21:39 | <Hixie> | heycam: what's the default default value of a dictionary member? |
21:39 | <Scorchin> | hober: :D |
21:39 | <heycam> | Hixie, default default? :) |
21:39 | <heycam> | Hixie, there's no such thing. the dictionary member is not present. |
21:39 | <tantek> | hello, is this the unofficial TPAC 2011 backchannel? |
21:40 | <Scorchin> | Wow, that Marriott has meeting rooms named after Californian cities/towns. That's not at all confusing to hear over the phone. |
21:40 | <heycam> | tantek, I thought that would be #tpac in irc.w3.org |
21:41 | <Philip`> | That doesn't sound very unofficial |
21:41 | <tantek> | heycam, #tpac in irc.w3.org is the *official* backchannel |
21:41 | <Hixie> | heycam: ah ok |
21:41 | <gsnedders> | How about #nottpac on irc.w3.org? :P |
21:41 | <Hixie> | heycam: so basically it's whatever the prose says? |
21:41 | <Hixie> | ok |
21:41 | heycam | missed the "un" |
21:41 | <heycam> | Hixie, yes, it's invalid for the prose to uncondtionally get the value of such a dictionary member, since it may not be present |
21:42 | <Hixie> | [24~k |
21:43 | <zewt> | tty smash |
21:44 | <Ms2ger> | Did Hixie bring a cat to TPAC? |
21:44 | <annevk> | heycam, setting it to undefined, is that the same as not present? |
21:44 | <Ms2ger> | No |
21:45 | <annevk> | guess it would end up meaning the same |
21:45 | <gsnedders> | annevk: No, it wouldn't. |
21:45 | <gsnedders> | annevk: hasOwnProperty would return a different value. |
21:46 | <heycam> | annevk, wouldn't mean the same thing. maybe the default value is something not just a constant value. you need to describe that in prose rather than idl. |
21:47 | <annevk> | gsnedders, I was talking about new EventSource(..., {withCredentials:undefined}) |
21:47 | <heycam> | annevk, oh sorry I misunderstood |
21:47 | <heycam> | that's the topic of the recent thread on public-script-coord |
21:47 | <annevk> | heycam, should event dictionaries have default values? |
21:48 | <annevk> | euh, dictionaries |
21:48 | <annevk> | I guess in general you don't really want that |
21:48 | <annevk> | so maybe that should just be dropped |
21:49 | <heycam> | default values are probably sensible in most cases I would've thought |
21:53 | <slightlyoff> | if you don't have a default, you should throw when you don't get everything. I'd have thought that defaults are obviously useful |
21:53 | <jgraham> | +1 |
21:55 | <annevk> | ew |
21:55 | <slightlyoff> | ew? |
21:55 | <annevk> | for event constructors you don't need a default |
21:55 | <annevk> | but you don't want to require everything |
21:55 | <jgraham> | The defult could be "undefined" |
21:56 | <slightlyoff> | if you're passing property bags, you should have defaults for things you don't pass in as configuration |
21:56 | <slightlyoff> | that's part of the win |
21:56 | <annevk> | the defaults can be magic in case of events |
21:56 | <slightlyoff> | so if I have a ctor like "new Thinger({ ... }); |
21:56 | <jgraham> | It should make it easier to spec |
21:56 | <annevk> | e.g. MouseEvents |
21:56 | <slightlyoff> | the value of the arguments object is that it doesn't require everything |
21:56 | <slightlyoff> | you could *optionally* have, say, 15 params |
21:56 | <jgraham> | If you don't have defaults you have to say if x is missing... |
21:56 | <slightlyoff> | but this might still be legal: |
21:56 | <annevk> | jgraham, I don't think it is |
21:57 | <slightlyoff> | new Thinger({ prop: "value" }); |
21:57 | <annevk> | jgraham, feel free to rewrite event constructors in an easier way though |
21:57 | <slightlyoff> | the other 14 should be defaulted |
21:57 | <heycam> | yes |
21:57 | <jgraham> | annevk: I don't understand why you think it is bad |
21:57 | <Hixie> | if you change event constructors please bear in mind this requires changes to a bunch of specs now |
21:57 | <annevk> | jgraham, I don't understand why you think it is simpler |
21:57 | <slightlyoff> | that's not design feedback = ) |
21:57 | <jgraham> | Because you know that you always have a value for everything |
21:57 | <heycam> | it's simpler because the defaults are in the idl for these cases |
21:58 | <jgraham> | It cuts down the number of cases |
21:58 | <annevk> | but you already need to define a default anyway |
21:58 | <heycam> | you don't need to with dictionaries |
21:58 | <heycam> | i think in this case we should though! |
21:58 | <annevk> | because the whole property bag is optional |
21:58 | <heycam> | but that's different, you probably will have a step in your constructor that says "if the options param was specified..." |
21:58 | <jgraham> | Right, but a missing bag is obviously the same as a bag with all the default values |
21:58 | <heycam> | and that's easier than having that conditional on every dictionary member when you say in the algorithm to look it up |
21:58 | <slightlyoff> | well, missing == {} |
21:59 | <annevk> | jgraham, not sure how that would even work for defining createEvent |
21:59 | <heycam> | there are no default values for operation arguments though |
21:59 | <slightlyoff> | in ES 6, you'd write it as: |
21:59 | <heycam> | so that still needs to be handled in rpose too |
21:59 | <slightlyoff> | function Thinger(args={}) { ... } |
21:59 | <slightlyoff> | new Thinger(); |
21:59 | <heycam> | so ES6 is a different thing then |
21:59 | <annevk> | the way it currently works is that you have requirements for when you create an event |
21:59 | <slightlyoff> | or if you want defaults in the param: |
21:59 | <heycam> | if we want to update webidl to allow targetting es6 stuff then that's fine, but atm you can't |
21:59 | <annevk> | and separately requirements for what to do with the init dictionary |
22:00 | <annevk> | if there is any |
22:00 | <slightlyoff> | function Thinger(args={ prop1: "...", prop2: "...", ...}); |
22:00 | <slightlyoff> | that's just strictly sugar |
22:00 | <heycam> | in fact that may be how an ES6-targetting webidl is written |
22:00 | <slightlyoff> | I was using it as an example of what you can obviously have WebIDL do for us today |
22:00 | <slightlyoff> | *sigh* |
22:01 | heycam | is confused |
22:01 | <heycam> | defaults for option objects are workable in webidl today |
22:01 | <slightlyoff> | yep |
22:01 | <slightlyoff> | and it's valuable! |
22:01 | <heycam> | yes :) |
22:01 | <slightlyoff> | we should have it, full stop |
22:02 | <zcorpan> | annevk: would be nice if parser.js had a comment at the top saying which rev it implements and how it differs from the spec (at that rev) |
22:02 | <annevk> | zcorpan, I should just fix the bugs |
22:02 | <annevk> | but probably not this week :( |
22:03 | <zcorpan> | annevk: i was planning on using it |
22:03 | <annevk> | not anymore? |
22:03 | <annevk> | it implements the revision just before hixie made all the changes based on your feedback :) |
22:04 | <zcorpan> | no i still am :) |
22:05 | <zcorpan> | was it in github or something? |
22:06 | <annevk> | zcorpan, https://bitbucket.org/annevk/webvtt |
22:06 | <annevk> | zcorpan, just uploaded my local changes |
22:07 | <zcorpan> | thanks |
22:07 | Ms2ger | runs away before someone pulls off his mask |
22:08 | <annevk> | trololol |
22:08 | <zcorpan> | annevk: maybe i can run it on the "srt converted to vtt" data and see which conformance errors are most common :) |
22:15 | zcorpan | thinks it would be nicer with align:middle instead of A:middle |
22:16 | <zcorpan> | why use one-letter for the setting but not the value? |
22:18 | <zewt> | definitely not a fan of vtt's abbreviations, personally |
22:23 | <zcorpan> | ok filed a bug |
22:24 | <zewt> | i forget the rationale for the abbreviations, just feels like trying to do deflate's job at the wrong level |
22:25 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14646 - please bikeshed what the settings should be called :) |
22:32 | <annevk> | "please bikeshed" oh god |
22:42 | <gsnedders> | What was the conclusion with innerText and Gecko? |
22:43 | <annevk> | no conclusion? |
22:44 | <gsnedders> | That's what I thought. |
22:51 | <zcorpan> | i think Hixie dropped <time> just for the puns |
22:52 | <gsnedders> | All the <data> is Hixie's? |
22:52 | <annevk> | All the <base> are belong to Hixie? |
22:53 | <gsnedders> | annevk: Dude, it's not 2001. |
22:55 | <annevk> | <br>eaking <b>ad |
22:55 | annevk | is bad at HTML puns |
22:57 | <annevk> | okay |
22:57 | <annevk> | so you have |
22:57 | <annevk> | new Event(x, dict) |
22:57 | <annevk> | and you have |
22:57 | <annevk> | document.createEvent(eventInterface) |
22:57 | <annevk> | the latter does not have access to x and dict |
22:57 | <annevk> | but they still need to be defined |
22:58 | <annevk> | so instead DOM defines how they are all initialized when you create an event object |
22:58 | <annevk> | and how dict overwrites anything, if any |
22:58 | <annevk> | (everything from okay above is for jgraham) |
23:02 | <jgraham> | Just define createEvent(x) as being equivalent to new Event(x, {}) |
23:02 | <heycam> | not exactly |
23:03 | <heycam> | x == "MouseEvent" for example |
23:03 | <heycam> | for the former |
23:03 | <heycam> | but "click" for the latter |
23:03 | <heycam> | (well the latter you'd want new MouseEvent(...)) |
23:03 | <annevk> | x != eventInterface |
23:03 | <jgraham> | Oh, OK |
23:04 | <heycam> | but I agree with the general approach |
23:04 | <heycam> | we need to make sure though that individual event/constructors always have default values for all dictionary members |
23:04 | <heycam> | so that createEvent's definition doesn't need to worry about that |
23:04 | <jgraham> | Yes |
23:04 | <heycam> | or, that constructors for events are all defined in the same way |
23:04 | <annevk> | you don't do that by defining default values for dictionary members |
23:05 | <annevk> | you do that by defining default values for the attributes |
23:06 | heycam | is not sure about that |
23:06 | <heycam> | unless that's part of the definitions you have in dom4 |
23:06 | <jgraham> | It just seems like a reasonable invariant that dictionary members always have values |
23:07 | <annevk> | heycam, it is, and it is how HTML defines it's events as well |
23:07 | <heycam> | ok |
23:07 | <annevk> | leading to me thinking that we should not have "= false" or some such in dictionaries |
23:09 | <heycam> | and just assume whatever undefined converts to? |
23:12 | <annevk> | well you have boolean withCredentials |
23:12 | <zewt> | annevk: looking at Progress Events as an example, where is the initialization of ProgressEvent from a ProgressEventInit defined? somewhere in webidl? (don't see it in [Constructor]) |
23:12 | <annevk> | if you set that to undefined, I guess it will make that false |
23:12 | <annevk> | zewt, DOM4 |
23:13 | <zewt> | found it |
23:13 | <zewt> | annevk: might be useful for eventInitDict to be a ref to dom4 Constructing events |
23:14 | <annevk> | maybe for "Constructor" |
23:14 | <zewt> | well that would ref webidl [Constructor] if anything, right? |
23:14 | <annevk> | no |
23:15 | <annevk> | typically it refers the definition in the draft |
23:15 | <zewt> | i mean the word Constructor is from webidl, it's "eventInitDict" that ties to dom4 |
23:15 | <annevk> | no |
23:15 | <annevk> | eventInitDict is just a meaningless name |
23:16 | <zewt> | it's definitely not meaningless, the name is given specific meaning in dom4 |
23:16 | <annevk> | no |
23:16 | <annevk> | you cannot give parameter names meaning |
23:16 | <annevk> | that's nonsense |
23:16 | <zewt> | you did give parameter names meaning |
23:16 | <annevk> | in fact |
23:16 | <annevk> | if I did that, type would be undefined |
23:16 | <annevk> | no I didn't |
23:16 | <zewt> | anyway the only point was to make it easier to see where this is defined |
23:17 | <annevk> | right, for that it would make sense to link Constructor, as we do elsewhere |
23:18 | <zewt> | jgraham: i think a (the?) benefit of defining the defaults anne's way is that if you ever construct an event interface in more than one way (eg. internally), you have all of the defaults in one place |
23:19 | <zewt> | since if you construct an event internally (eg. "fire a progress event"), you're not using the dictionary at all |
23:19 | <jgraham> | Yeah, I see that. But I am not sure that is the most important property |
23:20 | <zewt> | other than that they seem roughly equivalent to me |
23:20 | <jgraham> | I could be wrong of course |
23:20 | <zewt> | if you could drop the prose initialization entirely then I'd agree, since it's just more concise to put them in the idl |
23:21 | <zewt> | (agree on first look anyway, might be other factors I don't know about) |