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)