| 03:31 | <wycats> | jamesr: the former |
| 03:31 | <wycats> | well |
| 03:31 | <wycats> | no |
| 03:31 | <wycats> | it means that addEventListener('foo') is meaningful |
| 03:31 | <wycats> | foo will ever be generated |
| 03:31 | <jamesr_> | foo will be generated by whom? |
| 03:31 | <jamesr_> | and in response to what? |
| 03:32 | <wycats> | jamesr: the HTML5 spec lists events that are generated by specific elements in certain circumstances, correct? |
| 03:32 | <wycats> | let's say HTML spec |
| 03:32 | <jamesr_> | do you have a specific example of what object you would ask this question about and what event? |
| 03:33 | <wycats> | an HTMLInputElement generates a change event |
| 03:33 | <wycats> | addEventListener |
| 03:33 | <wycats> | addEventListener('change') is meaningful |
| 03:33 | <wycats> | while addEventListener('wtf') is meaningless |
| 03:33 | <wycats> | the list of supported events is part of the interface of an object |
| 03:33 | <jamesr_> | why - i could construct a 'wtf' event and fire it at your <input> event |
| 03:34 | <wycats> | jamesr: you could also install an onwtf property on HTMLInputElement.prototype |
| 03:34 | <jamesr_> | <input> element, that is |
| 03:34 | <wycats> | but that's besides the point |
| 03:34 | <jamesr_> | how so? |
| 03:34 | <wycats> | the list of events specified by the spec is an important part of the interface |
| 03:35 | <jamesr_> | sounds like you want to ask if a given thing will _generate_ an event |
| 03:35 | <wycats> | well... I originally asked about WebIDL |
| 03:35 | <wycats> | so I don't want to do it via code |
| 03:35 | <wycats> | I want to see it in the WebIDL interface for HTMLInputElement |
| 03:36 | <jamesr_> | the WebIDL interface is you can register a handle for any event you want |
| 03:36 | <jamesr_> | because any event might be fired at the element |
| 03:36 | <wycats> | and I'm saying that the fact that only certain events are specified in the spec is an important part of the interface |
| 03:37 | <wycats> | I understand that WebIDL doesn't provide a mechanism for doing it today |
| 03:37 | <wycats> | but it seems useful |
| 03:37 | <jamesr_> | only some events are specified as being fired at the element, but it's in no way an exhaustive list of what could be fired at that element |
| 03:37 | <wycats> | it's an exhaustive list of the events that are specified to be fired at the element |
| 03:37 | <jamesr_> | it's easy to say "yes, change could be fired at HTMLInputElement" but i have no idea how to decide whether or not wtf |
| 03:37 | <jamesr_> | there is no such thing |
| 03:37 | <jamesr_> | it's specified that you can fire anything at the element |
| 03:37 | <wycats> | jamesr: yes there absolutely is |
| 03:38 | <wycats> | jamesr: you can also add any property to the element |
| 03:38 | <wycats> | that doesn't matter |
| 03:38 | <jamesr_> | why doesn't it matter? |
| 03:38 | <wycats> | there is a list of events that the spec says will be fired under certain circumstances |
| 03:38 | <wycats> | that list is an important part of the interface |
| 03:38 | <wycats> | if you don't think it is, why? |
| 03:39 | <Hixie> | there is no such list |
| 03:39 | <wycats> | there is an implied list |
| 03:39 | <jamesr_> | i think you think there is such a list, and i'm telling you no such thing exists |
| 03:40 | <wycats> | throughout the spec, there is language that instructs the user agent to fire an event in certain circumstances |
| 03:40 | <wycats> | there is a finite number of those instructions, and they are specified against specific subsets of all available elements |
| 03:40 | <wycats> | that means that for a given element, there is a list of events that the spec knows about |
| 03:40 | <wycats> | just like there is a list of properties or attributes that the spec knows about |
| 03:41 | <jamesr_> | (and any element that's a parent of those elements) |
| 03:41 | <wycats> | yes, as a consequence of bubbling |
| 03:42 | <wycats> | for a given event target, there is a finite list of events |
| 03:42 | <wycats> | that the spec knows about |
| 03:42 | <wycats> | the list of events that will be fired directly on an event target is a useful part of the interface |
| 03:44 | <jamesr_> | can you give a concrete example? |
| 03:50 | <wycats> | probably more readily in person |
| 03:50 | <wycats> | this conversation is veering off for me |
| 03:50 | <wycats> | I think I could probably make my point if I focused exclusively on extreme precision for a while |
| 03:52 | <jamesr_> | i just want to know the one line of code you really want to write |
| 03:53 | <zewt> | wycats: no, any event target can receive any event |
| 03:53 | <wycats> | jamesr: this is not about lines of code |
| 03:54 | <wycats> | it's about reading the spec and understanding something import |
| 03:54 | <wycats> | important* |
| 03:54 | <Hixie> | wycats: there is language that in at least two places means the set of possible events that can fire on a given object is infinite |
| 03:54 | <wycats> | let me try to be precise |
| 03:54 | <zewt> | particular apis happen to only fire specific ones, but anyone can dispatch events directly and it's exactly the same (except for a few unfortunate and isolated exceptions) |
| 03:54 | <wycats> | Hixie: there is also language that allows infinite attributes on elements |
| 03:54 | <Hixie> | wycats: (namely, dispatchEvent() for any EventTarget, and EventSource's processing model) |
| 03:54 | <wycats> | but that is irrelevant |
| 03:54 | <Hixie> | wycats: how is it irrelevant? there's similarly no way to detect if a particular attribute can exist on an element :-) |
| 03:55 | <wycats> | I am not talking about detection |
| 03:55 | <Hixie> | (sorry for only posting occasionally, i'm just popping in during ad breaks here :-) ) |
| 03:55 | <wycats> | I am talking about formalizing a concept in the spec |
| 03:55 | <wycats> | instead of via prose |
| 03:55 | <zewt> | events are specified in terms of dispatching--not receiving |
| 03:55 | <Hixie> | wycats: what is the concept you want to formalise? |
| 03:56 | <wycats> | a list of events that the spec instructs the user agent to fire directly at an event target in some situation |
| 03:57 | <wycats> | http://dev.w3.org/html5/spec/single-page.html#the-a-element |
| 03:57 | <wycats> | Here, we have a list of attributes |
| 03:57 | <wycats> | This is not exhaustive |
| 03:57 | <wycats> | the spec allows any attribute |
| 03:57 | <jamesr_> | so you want to ask the UA what _it_ might fire at your element |
| 03:57 | <wycats> | but there's a list of attributes that have specific meaning in the spec |
| 03:57 | <jamesr_> | not ask your element what might be fired at it |
| 03:57 | <jamesr_> | right? |
| 03:57 | <wycats> | correct |
| 03:57 | <wycats> | except that I don't want the answer via code |
| 03:58 | <zewt> | wycats: attributes are specified because attributes have meaning *to* the element; events have no meaning to elements (again with a couple exceptions they never do anything when they receive events, except forwarding them to on* attributes of course) |
| 03:58 | <wycats> | I want the spec to have a section "events" which is a list of events that the spec instructs the user agent to fire in certain circumstances |
| 03:58 | <wycats> | define "have meaning to the element"? |
| 03:59 | <zewt> | elements don't do anything with events; they pass them on to on* attributes and that's it |
| 03:59 | <jamesr_> | there are default event handlers |
| 04:00 | <zewt> | those are part of the dispatcher, not the receiver |
| 04:00 | <jamesr_> | ah true |
| 04:00 | <jamesr_> | wycats: could you just look for things in the spec that invoke the 'dispatch an event…' algorithm? |
| 04:00 | <jamesr_> | probably could generate that with a script |
| 04:02 | <wycats> | jamesr_: that would depend on how judicious the spec-writer was about using precisely the right language in the right place in prose |
| 04:02 | <zewt> | fundamentally it doesn't seem good to spec this normatively because it would be redundant with the dispatch "side", which means redundant normative text (which is a big opportunity for specs to be self-contradicting) |
| 04:03 | <zewt> | wycats: if they're not doing that, they're probably also not going to keep these sorts of lists up to date either :) |
| 04:03 | <wycats> | zewt: can you describe to me how I could programmatically extract this information from the current spec? |
| 04:03 | <zewt> | you'd have to ask someone familiar with the spec's markup |
| 04:04 | <wycats> | zewt: to the best of my ability to read the spec, there isn't sufficient consistency in how event dispatching is described in prose to make your approach feasible |
| 04:04 | <zewt> | wycats: don't think that was me :) |
| 04:05 | <Hixie> | wycats: really now, you're citing the dev.w3.org copy? :-) |
| 04:06 | <wycats> | Hixie: oh noes |
| 04:06 | <Hixie> | wycats: (for the record, that copy is way out of date at this point, with numerous new errors beyond even the ones that are just ones i've fixed in the whatwg copy that they haven't taken yet) |
| 04:06 | <wycats> | Hixie: I stand by my original claim that the list of events that the spec instructs the user agent to fire directly on a particular event target is an important part of the interface of an event target |
| 04:06 | <Hixie> | wycats: i don't understand why |
| 04:07 | <wycats> | Hixie: that is very surprising to me |
| 04:08 | <Hixie> | wycats: wycats is it a more important part of the interface that the activation behaviour? |
| 04:08 | <zewt> | assuming you're talking normative text, what requirements would this place, exactly? "it must be possible for something, somewhere to fire each of the following events"? |
| 04:08 | <Hixie> | wycats: or than the content model? |
| 04:09 | <wycats> | Hixie: the content model is listed normatively at the top of every element |
| 04:09 | <Hixie> | wycats: or than the elements' meaning? |
| 04:09 | <zewt> | i mean, i might (unsure) agree if you were talking a non-normative "here are the things that are explicitly fired on this" note, but normatively I don't understand |
| 04:09 | <Hixie> | wycats: in prose |
| 04:09 | <Hixie> | wycats: same as what events fire |
| 04:09 | <wycats> | let's forget I asked about WebIDL for a second |
| 04:09 | <wycats> | there are lists of characteristics of elements in the spec |
| 04:10 | <wycats> | at the top of each element |
| 04:10 | <Hixie> | wycats: most of them (all, in a point of fact, other than the idl) in prose |
| 04:10 | <zewt> | events have no characteristics from the point of view of the element; the element knows nothing about them |
| 04:10 | <wycats> | some of those lists have information duplicated in the prose |
| 04:10 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/#the-a-element |
| 04:10 | <Hixie> | i don't think there's much duplication |
| 04:10 | <Hixie> | but maybe we have a different understanding of "in prose" |
| 04:10 | <wycats> | Do you consider the parts in the green box prose? |
| 04:10 | <Hixie> | all but the idl boxes, yes |
| 04:10 | <wycats> | I am suggesting adding it to the green box |
| 04:11 | <Hixie> | can you give an example of what it would say? |
| 04:11 | <Hixie> | say, for the <a> element? |
| 04:11 | <wycats> | I also think it belongs in the IDL box, but I will defer that discussion |
| 04:11 | <wycats> | Events:\nclick\netc. |
| 04:11 | <wycats> | possibly by pointing to some other part of the spec |
| 04:11 | <wycats> | similar to Global Attributes |
| 04:11 | <zewt> | that means every single element would include "click" |
| 04:11 | <wycats> | there could be Global Events |
| 04:11 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/#global-attributes |
| 04:12 | <wycats> | zewt: indeed it would |
| 04:12 | <zewt> | (well, rendering ones; obviously not <link>) |
| 04:12 | <wycats> | zewt: this kind of problem is already addressed for other things in the green box |
| 04:12 | <wycats> | Hixie: what should I call "things in the green box"? |
| 04:13 | <Hixie> | wycats: you just want a non-normative list of events that ...something, what, are mentioned in that section? for each element? |
| 04:13 | <zewt> | (can you clarify whether you're talking normative or non-normative?) |
| 04:13 | <Hixie> | wycats: "things in the green box" |
| 04:14 | <Hixie> | zewt: actually the HTML spec doesn't fire 'click' on most elements, that would be the (non-existent?) user-interface spec (exceptions for if the element has an activation behaviour), and here's no difference between <link> and <a> in that respect |
| 04:14 | <Hixie> | zewt: (you can click on a <link>, just make it display:block) |
| 04:14 | <wycats> | zewt: is the green box normative? |
| 04:14 | <Hixie> | parts of the green box are normative |
| 04:14 | <zewt> | wycats: hixie will tell me if i'm wrong, but unless it says "this box is non-normative" it is |
| 04:14 | <wycats> | which parts? |
| 04:14 | <wycats> | zewt: then I am talking about normative |
| 04:14 | <Hixie> | categories, content model, dom interface |
| 04:14 | <wycats> | a la the attributes |
| 04:15 | <Hixie> | i guess content attributes also, to a small extent |
| 04:15 | <wycats> | Hixie: Content attributes is non-normative? |
| 04:15 | <zewt> | normative is the parts that place requirements on things; non-normative (informative/notes) is stuff that doesn't (again modulo hixie :) |
| 04:15 | <Hixie> | (see http://www.whatwg.org/specs/web-apps/current-work/#element-definitions for a precise answer) |
| 04:15 | <wycats> | zewt: I am aware of the definition :P |
| 04:15 | <wycats> | Content attributes are duplicated in the prose below the green box |
| 04:15 | <zewt> | and i don't know what possible requirements this would be placing |
| 04:16 | <wycats> | if you eliminated the list of attributes, you could determine it by reading the prose |
| 04:16 | <wycats> | so why do we have a list? |
| 04:16 | <Hixie> | the "content attributes" normatively states which attributes MAY be specified, it's a conformance criteria just for authors/validators |
| 04:16 | <Hixie> | it's overridden for some attributes in the prose by MUST/MUST NOT be specified |
| 04:16 | <Hixie> | the definitions of the attributes of course aren't in the green box, they're all in prose |
| 04:16 | <Hixie> | later |
| 04:17 | <Hixie> | if we didn't have that list, we'd have to have it somewhere else saying "and you MAY have this attribute, and that attribute, and that one, and this one..." |
| 04:17 | <wycats> | Hixie: we already specify the definition of those attribtues |
| 04:17 | <wycats> | attributes |
| 04:17 | <Hixie> | ? |
| 04:17 | <wycats> | the definition of href is in prose |
| 04:17 | <wycats> | so we don't also need it in a list |
| 04:18 | <Hixie> | the list doesn't have the definition, right |
| 04:18 | <wycats> | "If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor)." |
| 04:18 | <Hixie> | "it just has the MAY be specified" |
| 04:18 | <wycats> | Hixie: right |
| 04:18 | <Hixie> | what you just quoted is orthogonal, it's a requirement on browsers |
| 04:18 | <wycats> | Hixie: and the events would be "a user agent MAY fire this event on this event target" |
| 04:18 | <zewt> | (by the way, isn't "this list seems redundant, so another redundant list is okay too" an odd argument? :) |
| 04:18 | <Hixie> | (and authors, to the extent that authors are required to use elementsfor their meaning) |
| 04:18 | <Hixie> | wycats: woah! woah! |
| 04:18 | <Hixie> | wycats: that would be wildly wrong |
| 04:18 | <wycats> | would it? |
| 04:18 | <Hixie> | wycats: yes! |
| 04:19 | <wycats> | Hixie: say more |
| 04:19 | <Hixie> | wycats: browsers damn well better not randomly fire events! |
| 04:19 | <Hixie> | wycats: they MUST fire events exactly at specified times! |
| 04:19 | <Hixie> | wycats: that's not a MAY |
| 04:19 | <wycats> | Hixie: that's what the prose is form |
| 04:19 | <wycats> | for* |
| 04:19 | <wycats> | just like attributes |
| 04:19 | <Hixie> | wycats: ??? |
| 04:19 | <Hixie> | this is nothing like attributes |
| 04:19 | <wycats> | ok |
| 04:19 | <wycats> | it's nothing like attributes |
| 04:20 | <wycats> | I would like a list of all of the events that the spec instructs the user agent to fire against an event target in some situation, and for them to be listed along with the specific event targets that they are specified to be fired on |
| 04:21 | <Hixie> | the spec instructs the user aget to fire every event against every EventTargets in some situation or other. |
| 04:21 | <Hixie> | (because of dispatchEvent, e.g.) |
| 04:21 | <wycats> | When I say "fire", I mean initialize and dispatch it to an event target |
| 04:22 | <wycats> | I do not mean the subsequent bubbling |
| 04:22 | <wycats> | "Note: Fire is short for initializing and dispatching an event." |
| 04:22 | <wycats> | that's what DOM4 says |
| 04:22 | <wycats> | "Note: Fire an event is a concept to make initializing and dispatching an event easier to write down." |
| 04:22 | <wycats> | from HTML: "In the contexts of events, the terms fire and dispatch are used as defined in the DOM Core specification" |
| 04:25 | <wycats> | so I am asking for a list of event types that the user agent is instructed to initialize and dispatch to an element in some circumstance |
| 04:25 | <zewt> | (event.dispatchEvent() uses the term "dispatch" to fire an arbitrary, user-created event) |
| 04:26 | <wycats> | zewt: I am excepting user-created events from my request |
| 04:26 | <wycats> | I mean event names that the specification explicitly defines |
| 04:27 | <Hixie> | well you can just click on the word "dispatch" in the HTML spec and it'll give you that answer |
| 04:28 | <Hixie> | hm, i guess not |
| 04:28 | <Hixie> | i haven't cross-referenced it enough |
| 04:28 | <zewt> | Hixie: there aren't many yeah |
| 04:28 | <Hixie> | ok then search for the words "fire" and "dispatch" :-) |
| 04:28 | <zewt> | that would probably be a big enough list to make the xref popup unhappy :) |
| 04:28 | <Hixie> | hm, searching for "fire" brings up the "firefox" in each status box |
| 04:28 | <Hixie> | that sucks |
| 04:28 | <zewt> | (i use "fire ") |
| 04:29 | <Hixie> | oh that works |
| 04:30 | <zewt> | "fire a simple event" at least seems pretty consistently xref'd |
| 04:30 | <Hixie> | yeah, that existed and meant something specific before dom core existed |
| 04:30 | <zewt> | (that one predates dom4, right?) |
| 04:31 | <Hixie> | searching for dispatch isn't so hot |
| 04:32 | <zewt> | seems like the only major false positive is "track dispatch type" |
| 04:34 | <zewt> | afk |
| 04:34 | <Hixie> | wycats: anyway, i don't really see what such a list would bring to the table. it's redundant with the text, and would always be getting out of date |
| 04:36 | <wycats> | Hixie: again, that is surprising to me |
| 04:36 | <wycats> | but I am not the intended consumer of the spec |
| 04:36 | <wycats> | so |
| 04:36 | <wycats> | seems good bros |
| 04:37 | <Hixie> | wait, you're asking for something you don't actually even want? :-) |
| 04:44 | <wycats> | I absolutely want it |
| 04:44 | <wycats> | and I think it would be extremely valuable to "author" consumers of the spec |
| 04:47 | <wycats> | let's try an experiment: |
| 04:47 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element |
| 04:47 | <wycats> | I am an "author" |
| 04:47 | <wycats> | I would like to learn the interface for interacting with the video tag |
| 04:47 | <wycats> | how does one go about doing this? |
| 04:48 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents |
| 04:48 | <Hixie> | next :-) |
| 04:49 | <Hixie> | (keeps going out of sync with the normative parts of the spec and is a pain in the ass to maintain, but for <video> it's probably worth it) |
| 04:53 | <wycats> | do you not consider it a problem that the event list is not together with the element? |
| 04:53 | <wycats> | I didn't ask you to link me to the event list |
| 04:54 | <Hixie> | how do you mean it's not together with the element? it's right there in the element's section! |
| 04:54 | <wycats> | I asked you to tell me how someone who goes to the video tag in the multipage spec can figure it out |
| 04:54 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element |
| 04:54 | <wycats> | scroll down |
| 04:54 | <Hixie> | (well, media elements section) |
| 04:54 | <wycats> | until you read "the audio element" |
| 04:54 | <wycats> | yes! |
| 04:54 | <smaug____> | Hixie: I was very surprised that you decided to change MutionObserver handling in the spec |
| 04:54 | <smaug____> | there are no technical reasons for it |
| 04:55 | <wycats> | why isn't it referenced from the element? |
| 04:55 | <Hixie> | smaug____: it wasn't my intention to change it, i just had forgotten to update the spec to say "mutation events and observers" everywhere. but i don't really have a strong opinion either way, i'll just do what the browser vendors want to implement. i kinda assumed it'd be costly to have to track every single insertion in parsing a document. |
| 04:56 | <Hixie> | wycats: the video and audio elements are basically the same, and their processing model is tightly integrated with the source and track elements', so all four are defined in one section, "media elements", to which each of those sections links. |
| 04:56 | <smaug____> | you don't need to track every insertion unless you have mutation observers |
| 04:56 | <Hixie> | smaug____: it's at least a branch for each insertion |
| 04:56 | <smaug____> | and mutation observer are anyway *a lot* cheaper than mutation events |
| 04:56 | <Hixie> | smaug____: if you're trying to convince me there is no need :-) |
| 04:56 | <smaug____> | Hixie: so? |
| 04:57 | <smaug____> | in code there are many branches :) |
| 04:57 | <Hixie> | smaug____: like i said, i'm happy to do whatever browsers want to implement |
| 04:57 | <smaug____> | we decide to either implement some feature or not |
| 04:58 | <smaug____> | Hixie: so, Gecko is happy to implement MutationObserving during parsing |
| 04:58 | <smaug____> | and not happy to not have it |
| 04:58 | <Hixie> | smaug____: so i saw from jonas' e-mail earlier tonight |
| 04:59 | <Hixie> | smaug____: hopefully you are not in the minority, and it becomes a non-issue and i just update the spec |
| 04:59 | <Hixie> | wycats: (where would you put that table otherwise?) |
| 05:00 | <smaug____> | I believe, could be wrong here, that this is just a case a bit tricky to implement in webkit, so they don't want mutation observers during parsing |
| 05:00 | <wycats> | Hixie: I think it should be linked off of the green box |
| 05:00 | <wycats> | in a section called Events, with the name Media Events |
| 05:01 | <Hixie> | smaug____: get opera or microsoft to weigh in on your side then :-) (didn't the chrome guys say they had done this already?) |
| 05:01 | smaug____ | hates these fights about API sanity |
| 05:01 | <Hixie> | smaug____: you should probably not be involved in web standards work then, that's all we do :-) |
| 05:02 | <smaug____> | Hixie: but until this is clear, the spec shouldn't say anything about it |
| 05:02 | <Hixie> | wycats: i think if we had a table like this for every object and element it might make sense to have a place to link to it from in the green box, but this is simply not that common in practice (because for most elements there's zero or close to zero relevant events) |
| 05:02 | <smaug____> | or say that this is still unclear |
| 05:03 | <Hixie> | smaug____: if it's really 50/50 then yeah, i add one of those warnings that says "thar be dragons" |
| 05:03 | <Hixie> | smaug____: like with the video mime type handling |
| 05:03 | <Hixie> | smaug____: i'd need to speak to the opera, webkit, and IE guys first to work out where the chips actually lie |
| 05:04 | <smaug____> | yes, after that you could say something in the spec |
| 05:04 | <smaug____> | but please don't take your side before that |
| 05:07 | smaug____ | should learn... keep the APIs in separate specs so that you can control them yourself :) |
| 05:07 | <Hixie> | i don't have a side |
| 05:07 | <Hixie> | i really couldn't care less about this :-) |
| 05:07 | <wycats> | what is the controversy anyway? |
| 05:07 | <Hixie> | there is no controversy |
| 05:07 | <Hixie> | anyway, afk for a bit |
| 05:07 | <smaug____> | Hixie: you decided to add something to the spec, so you do have some opinion, or decided for some reason to follow what webkit devs want, but not what gecko devs want |
| 05:08 | <smaug____> | you could just leave the whole thing out from the spec for now |
| 05:08 | <Hixie> | smaug____: i just followed what the spec said already |
| 05:08 | <smaug____> | no |
| 05:08 | <Hixie> | get the other browsers to say something and i'll fix it tomorrow |
| 05:08 | <Hixie> | sheesh, relax dude |
| 05:08 | <smaug____> | MutationObserver is totally different thing to Mutation Events |
| 05:10 | <smaug____> | yeah, I could relax :) , but when random stuff ends up to the specs, there is something to fix |
| 05:17 | <zewt> | heh, messing around with setting a <script>'s display to block, hit a firefox bug almost immediately |
| 05:17 | <zewt> | in the list of Bugs That Nobody Cares About |
| 05:18 | <zewt> | (<script style="display: block;">foo();</script> doesn't show up by itself, but stick some text before it and it does) |
| 05:18 | <zewt> | hmm |
| 05:19 | <zewt> | maybe just really weird but intentional rendering behavior? since chrome does it, too |
| 05:19 | <zewt> | (not that I really care, either, just messing about) |
| 05:20 | <zewt> | or maybe something to do with implicit <head>/<body> |
| 05:21 | <zewt> | yeah, guess so (stick <link> before it and it doesn't show up; stick <div> and it does) |
| 05:21 | <zewt> | anyway, off to bed |
| 07:17 | <annevk> | oh god |
| 07:17 | <annevk> | someone respec'd DOM Parsing |
| 07:36 | <Ms2ger> | zewt, yep, your script was in the head, and head has display: none as well |
| 07:36 | <zcorpan> | Hixie: knowing that there aren't any relevant events fired on the element is useful to know for authors (just like with attributes) |
| 07:36 | <zcorpan> | Hixie: i agree with wycats that it would be useful for authors with non-normative information about events for each element (like the table for media elements) |
| 07:38 | <zcorpan> | for most of the spec, it has to be gathered by reading the UA requirements, which is not so nice for authors (and will even be omitted completely from the developers.whatwg.org version) |
| 07:48 | <zcorpan> | zewt: if you had tested in live dom viewer you would see where the script element lived in the dom :-) |
| 07:53 | <Ms2ger> | Hixie, you called after 2AM my time? |
| 08:00 | <annevk> | yeah, wycats had a good point, too bad it was badly misunderstood :/ |
| 08:21 | <jgraham> | OTOH Hixie has a point that increasing the amount of non-normative text leads to more things that can go out of sync |
| 08:27 | <zcorpan> | sure |
| 08:29 | <annevk> | is there any other info you'd want to know about an object that's not evident from IDL? |
| 08:46 | <zcorpan> | omission of tags maybe |
| 08:46 | <zcorpan> | but that's kinda complicated |
| 08:47 | <zcorpan> | Start tag: sometimes optional (with link to the right place in the syntax section) |
| 08:55 | <annevk> | that's element-specific |
| 08:55 | <annevk> | I was wondering about stuff like Node / XMLHttpRequest |
| 08:55 | <annevk> | but yeah, start/end tag stuff would be nice to have hints about |
| 09:04 | <jgraham> | Start/end tag stuff is unneeded complexity if the goal is to help authors |
| 09:04 | <zcorpan> | jgraham: yeah probably |
| 11:23 | <annevk> | https://twitter.com/andydavies/status/241117462068879360 euh, he realizes what those pages render in right? |
| 11:23 | <annevk> | oh well |
| 11:23 | <annevk> | see you guys next week |
| 11:25 | <Ms2ger> | Gone again? |
| 11:25 | <annevk> | just a few days |
| 11:25 | <annevk> | should be back Sunday night |
| 11:25 | <jgraham> | I presume he is going to ride the trains with the other hobos |
| 11:25 | <jgraham> | :) |
| 11:26 | <annevk> | dude, unemployed != hobo |
| 11:26 | <Ms2ger> | Rich hobo? |
| 11:26 | <jgraham> | "Unlike 'tramps', who work only when they are forced to, and 'bums', who do not work at all, 'hobos' are workers who wander" |
| 11:27 | <jgraham> | Is the WikiTruth |
| 11:27 | <jgraham> | Are you claiming that 'bum' would have been more accurate? |
| 11:29 | <jgraham> | (the more Wikipedia I read teh more I think my original usage is a good fit, although it wasn't intended in seriousness) |
| 11:34 | <zcorpan> | jgraham: edit wikipedia to say "One example of a hobo is Anne van Kesteren." |
| 11:35 | Ms2ger | whacks zcorpan with a banhammer |
| 11:36 | <jgraham> | Ms2ger: Is that like a cross between a hammaer and a banana? |
| 11:36 | <jgraham> | *hammer |
| 11:36 | <Ms2ger> | It's a hammer with a banana attached |
| 11:36 | <zcorpan> | Ms2ger: doesn't help much if jgraham makes the edit :-P |
| 11:38 | <annevk> | jgraham: can they have a home? |
| 13:45 | <zewt> | zcorpan: there are lots of ways to test the same thing :) |
| 13:47 | <zcorpan> | zewt: hmm? |
| 13:49 | <jgraham> | zcorpan: I can only imagine he is talking about the "you should have used the live dom viewer thing" |
| 13:50 | <jgraham> | s/ thing"/" thing/ |
| 14:24 | <Hixie> | Ms2ger: yt? |
| 14:24 | <Hixie> | Ms2ger: what's the doal with dom parsing? |
| 14:50 | <jgraham> | Hixie: How does the spec ensure that <script defer src> is run before DOMContentLoaded? |
| 14:51 | <jgraham> | Oh, sorry defer |
| 14:51 | <jgraham> | Wrong set|list of scripts |
| 14:52 | <Hixie> | yeah this part of the spec is absurdly complicated |
| 14:52 | <Hixie> | much like the rest of the parser and script processing |
| 14:52 | <Hixie> | or like <object> processing |
| 14:54 | <Ms2ger> | Hixie, Microsoft has forked parsing |
| 14:54 | <Hixie> | Ms2ger: so you're still editing your canonical version? |
| 14:54 | <Ms2ger> | I don't know if anyone else intends to pay attention to them |
| 14:54 | <Ms2ger> | Yeah |
| 14:54 | <Hixie> | phew |
| 14:55 | <jgraham> | Hixie: I'm pretty sure that navigation is more confusing than anything |
| 14:55 | <Hixie> | jgraham: hear hear |
| 14:55 | <Hixie> | Ms2ger: sounds like you may want to have mike create a component in the WHATWG product in bugzilla, and then move all the bugs over |
| 14:56 | <MikeSmith> | yeah I can do that |
| 14:56 | <Ms2ger> | Sounds good |
| 14:56 | <MikeSmith> | remind me later if I forget |
| 14:56 | <MikeSmith> | I have two hours of telcons starting right now |
| 14:57 | <Hixie> | sweet lord |
| 14:58 | <jgraham> | Ohh, I know this feeling. It's schadenfreude. |
| 14:58 | jgraham | laughs at MikeSmith |
| 14:58 | <MikeSmith> | hah |
| 15:27 | Hixie | has no idea what before() and after() do |
| 15:33 | <jgraham> | Hixie: How can you edit the HTML5 spec if you aren't spending half your time learning jQuery / backbone / modernizr / responsive design hacks / other trend de-jour? |
| 15:37 | <jgraham> | (since this is the internet I made a useful sign: [ SARCASM ] ) |
| 15:48 | darobin | sets his watch by dglazkov's greeting |
| 15:49 | <dglazkov> | :) |
| 15:52 | <Hixie> | jgraham: i am spending half my time (well, ok, maybe less than half) writing web apps (mainly games), but in doing so i haven't found much of a need for libraries. |
| 15:53 | <Hixie> | Ms2ger: :-P |
| 15:54 | <Hixie> | wasn't it mozilla that convinced me to make defer not apply to inline scripts in the first place? |
| 15:58 | <jgraham> | Uh, so async on inline scripts… that sounds like it would be remarkably similar to today (until modules) |
| 16:02 | <Ms2ger> | Hixie, that would probably be hsivonen, not mozilla ;) |
| 16:08 | <jgraham> | I thought it was usually Microsoft that did the referring-to-people-by-their-company thing |
| 16:11 | <hober> | Ms2ger: have you talked to travis about working together on the dom parsing spec? ideally the dvcs.w3.org one would be the same as yours |
| 16:12 | <Ms2ger> | hober, he does not appear to be interested to do that |
| 16:13 | <hober> | :( |
| 16:14 | <Ms2ger> | I'm glad that Microsoft has come out in support of forking, though |
| 16:16 | <hober> | hahahahaa. unidirectional forking maybe. |
| 16:17 | <Ms2ger> | Is that a nice word for "hypocrisy"? |
| 16:17 | <TabAtkins> | Hixie: el1.before(el2) inserts el2 into the document immediately before el1. |
| 16:21 | <jgraham> | Which is all kinds of wrong since it leaves el2 before el1 |
| 16:22 | <TabAtkins> | ...yes? There's the inverse, insertBefore(), if you want the other behavior. |
| 16:22 | <TabAtkins> | Depends on whether you're currently chaining with the element you want to insert, or the one you want to insert something around. |
| 16:23 | <jgraham> | I'm just saying that, ignoring the fact that "before" isn't a verb, it reads as the opposite of what it does |
| 16:23 | <TabAtkins> | Sure. Warping grammar to pl concepts is a hard problem. |
| 16:24 | <TabAtkins> | You quickly learn that before and insertBefore are identical save for the target/arg switch, and insertBefore is obviously more of a command to insert the target before the arg, so before must be the opposite. |
| 16:25 | <Ms2ger> | https://twitter.com/sgalineau/status/241152263119327232 |
| 16:27 | <TabAtkins> | Ms2ger: Was just reading http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-node and noted that the nodeValue and textContent attributes looks misaligned. They're not (the extra space is because they're not readonly), but could you sort them so all the attributes are together? |
| 16:27 | <jgraham> | I still find it hard to remember the right argument order for insertBefore, so that hardly seems like a point in its favour |
| 16:27 | <TabAtkins> | jgraham: Well then you're just hopeless. ^_^ |
| 16:28 | <Ms2ger> | That seems like a strange way to sort :) |
| 16:28 | <TabAtkins> | Ms2ger: How are they sorted currently? |
| 16:28 | <Ms2ger> | Sorta topical |
| 16:29 | Ms2ger | wonders how cloneNode and isEqualNode ended up grouped together |
| 16:30 | <jgraham> | "weird cousins that no one likes"? |
| 16:30 | <TabAtkins> | Emphasis on the "sorta". ^_^ At least, could you move the compareDocumentPosition bits to below the following sections? nodeValue and textContent are more like childNodes than an iterator. |
| 16:30 | <TabAtkins> | There's also a double blank line after normalize, which seems odd. |
| 16:31 | <Ms2ger> | Yeah |
| 16:31 | Ms2ger | had better learn to use hg-git, then |
| 16:31 | <jgraham> | Or, you know, git |
| 16:32 | <Ms2ger> | Nah, I tried that |
| 16:33 | <TabAtkins> | Where is it stored? It looks like dvcs.w3.org, which would just be normal hg. |
| 16:33 | <Ms2ger> | https://github.com/whatwg/dom |
| 16:33 | <TabAtkins> | Ah, interesting. |
| 16:34 | <TabAtkins> | I can just pull-request you, if you'd like. |
| 16:34 | <Ms2ger> | Nah, I need to figure it out anyway |
| 16:34 | <Ms2ger> | This is as good a time as any :) |
| 16:35 | <JonathanNeal> | hello |
| 17:25 | <paul_irish> | jgraham: since over half the web uses jQuery because DOM methods are verbose and uncomfortable it seems odd to discard its influence on web development so trivially. |
| 17:25 | <paul_irish> | basically all the hacks and libraries you list are created because the platform isn't good enough for developers to use directly |
| 17:26 | <paul_irish> | So... to ignore the way developers choose to interact with the platform seems to be at odds at delivering a platform developers can make good use of. |
| 17:28 | <Hixie> | there were some proposals made for function names that were short yet still clear, which seems like a win |
| 17:29 | <paul_irish> | definitely :) |
| 17:31 | <Hixie> | paul_irish: (the problem with just making new APIs match the style of the library-du-jour is that it leads to the platform having multiple personality disorder with different parts having different styles) |
| 17:32 | <Hixie> | paul_irish: (better IMHO to try to make the platform consistent with itself, while still learning from past mistakes like not having ultraverbose method names) |
| 17:32 | <Hixie> | paul_irish: (that way at least it has a single style, and then people can layer libraries over that if they want a different style, rather than people having to learn multiple styles to use the web without a library, and being forced ot use a library to paper over hte parts that have the styles they don't like) |
| 17:33 | <Hixie> | paul_irish: (still, we should obviously not _ignore_ the libraries) |
| 17:33 | <paul_irish> | That seems fair, though I don't know how sold I am on the value of consistency with DOM's legacy... |
| 17:33 | <Hixie> | well, consistency is relative |
| 17:33 | <paul_irish> | aye. |
| 17:33 | <paul_irish> | but yeah my larger point is that these are not du-jour libraries |
| 17:34 | <Hixie> | on the timescale of the web (dozens if not hundreds of years), the entire _web_ is "du jour" |
| 17:34 | <paul_irish> | du-decade :) |
| 18:21 | <scott_gonzalez> | Hixie: Regarding :enabled and :disabled, there was a bug filed for this as well https://www.w3.org/Bugs/Public/show_bug.cgi?id=18628 |
| 18:22 | <Hixie> | thanks for the heads-up |
| 18:22 | <Hixie> | will resolve the bug |
| 18:48 | <tantek> | Hixie, paul_irish, or eventually a single library becomes dominant enough to effectively become part of the platform, and it's at least even odds as to whether that's happening with jQuery. |
| 18:48 | tantek | waits for a jQuery Community Group to emerge. |
| 18:58 | <Hixie> | heycam|away: if i have a function in web idl overloaded like so: void f(DOMString s); void f(Callback c); where Callback is callback Callback = any (); |
| 18:59 | <Hixie> | heycam|away: is there any value that can be passed to f() that won't either be treated as a DOMString or a Callback? |
| 18:59 | <Hixie> | heycam|away: (and thus by extension, is there any way for [TreatNonCallableAsNull] to have an effect on Callback, or would it be completely redundant there?) |
| 19:00 | <Ms2ger> | Correct |
| 19:01 | <Hixie> | i didn't make any statements, how can my questions be correct :-P |
| 19:02 | <Ms2ger> | No / redundant |
| 19:02 | <Ms2ger> | You asked good questions! |
| 19:02 | <Hixie> | k :-) |
| 19:04 | <Hixie> | is there ever a case where the fragment algorithm is invoked without a context, these days? |
| 19:05 | <Ms2ger> | Was there ever one? |
| 19:06 | <Hixie> | document.innerHTML |
| 19:06 | <Ms2ger> | Oh |
| 19:06 | <Ms2ger> | Then probably not |
| 19:08 | <Hixie> | anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=17935 ? |
| 19:08 | <Hixie> | even assuming they mean ImageData rather than ImageInfo, I'm still at a loss |
| 19:10 | <Ms2ger> | I think they want to draw the pixels in the ImageData somewhere |
| 19:10 | <jgraham> | paul_irish: I made two seperate points, neither of which is |
| 19:12 | <jgraham> | "we should ignore libraries". One was the suggestion (which I have seen) that Hixie is not qualified to edit the spec because he is not always using the latest frameworks/libraries/fashioanble things/ is absurd. The other is that particular names that have been proposed for the DOM API are horrible, even though they match jQuery |
| 19:13 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0292.html |
| 19:13 | <Ms2ger> | But mailing lists are support forums! |
| 19:14 | Hixie | bops Ms2ger on the head with a flip flop |
| 19:14 | <Ms2ger> | :) |
| 19:15 | <Hixie> | why can't people who file bugs like https://www.w3.org/Bugs/Public/show_bug.cgi?id=15919 actually DO THE TESTING rather than asking ME to do it |
| 19:15 | <Hixie> | who does that guy think i am anyway |
| 19:16 | <Velmont> | The sole web platform QA :D |
| 19:17 | <jgraham> | You mean soul web platform QA, right? |
| 19:18 | <Ms2ger> | Hixie, well played |
| 19:18 | <jgraham> | That's why he gets a little R.E.S.P.E.C.T |
| 19:19 | <jgraham> | Hixie: I wonder if I wrote tests for that yet. I ought to have done but might well have not thought of that case |
| 19:19 | <Hixie> | jgraham: yeah, same here |
| 19:19 | <Hixie> | jgraham: (well, except obviously i did think of the case at some point) |
| 19:20 | <Hixie> | lunch first |
| 19:22 | <GrenBaykre> | So... |
| 19:22 | <GrenBaykre> | Are you folks responsible for WebGL? |
| 19:22 | <Ms2ger> | Unfortunately not |
| 19:23 | <Velmont> | Nah, Khronos thingy. |
| 19:23 | <GrenBaykre> | Well... |
| 19:23 | <GrenBaykre> | IE current doesn't even support WebGL at all. |
| 19:23 | <GrenBaykre> | That's a big-ass problem for me. |
| 19:23 | <GrenBaykre> | I need to be able to draw 3D stuff. |
| 19:24 | <GrenBaykre> | (Game/interactive art.) |
| 19:24 | <Velmont> | We're mostly Operaians, Mozillians and Googlefolks here though, of vendors. At least the ones that make the most noise. |
| 19:24 | <Velmont> | All of which have WebGL. |
| 19:24 | <GrenBaykre> | I am an Operian, but nobody gives a shit about what I am. |
| 19:24 | <GrenBaykre> | People use IE and other junk. |
| 19:25 | <Sidnicious> | :) |
| 19:25 | <Sidnicious> | GrenBaykre: Have you looked at stuff like https://github.com/mrdoob/three.js/ ? |
| 19:25 | <GrenBaykre> | Yes, I have tried to understand Three.js. |
| 19:25 | <GrenBaykre> | I have a number of questions which I find hard to articulate regarding it, though. |
| 19:26 | <GrenBaykre> | It appears to just be a framework/wrapper around, in theory, various "engines" to display the 3D stuff in a browser. |
| 19:26 | <GrenBaykre> | BUT all the examples I've seen of it using non-WebGL have looked like crap and been very slow. |
| 19:27 | <Velmont> | Well, if you really care that much about IE right now, then you can write 2d canvas for it. |
| 19:27 | <Velmont> | Erik Möller in Opera ported his game to both WebGL and 2D canvas, you can switch between them at runtime. |
| 19:28 | <Sidnicious> | GrenBaykre: Just poking through their change log, ran into this guy: http://iewebgl.com/Default.aspx |
| 19:30 | <GrenBaykre> | I don't know what you meant by that, Velmont. |
| 19:30 | <GrenBaykre> | Sidnicious: Oh... an evil, crazy hack! |
| 19:30 | <GrenBaykre> | Sidnicious: Those kinds of things really amaze me. |
| 19:30 | <GrenBaykre> | I think there was a "SVG inside Flash" for IE as well... hehe. |
| 19:30 | <Sidnicious> | heh |
| 19:31 | <GrenBaykre> | "IEWebGL is a plugin for Microsoft Internet Explorer web browser" <-- If it's an actual plug-in, that is virtually worthless, I'm afraid. |
| 19:31 | <GrenBaykre> | Because users won't install that. |
| 19:31 | <jgraham> | GrenBaykre: You have two basic choices: 1) Use WebGL get hardward acceleration. Don't support IE users and the large set of people without the right hardware for WebGL. 2) Don't do something that needs WebGL. |
| 19:31 | <GrenBaykre> | But if it's a .js and maybe a .swf... |
| 19:31 | <Sidnicious> | yeah, I got the impression it was an actual plugin too |
| 19:31 | <GrenBaykre> | Well, I need to do 3D stuff. I've prolonged it for a decade or more. |
| 19:32 | <jgraham> | If that means "hardware accelerated 3D" then there is currently no solution that will work for a majority of users |
| 19:32 | <jgraham> | IE users are only a subset of those that will be excluded |
| 19:33 | <GrenBaykre> | Well, actually, my 3D needs are (at least initially) extremely primitive, almost to compare with non-textured/wireframe things. |
| 19:33 | <GrenBaykre> | But all the 3D tests in Canvas have apparently been crap. |
| 19:33 | <Sidnicious> | I think Velmont meant that it would, technically, be possible to write your stuff for WebGL and also to draw on a <canvas>, and use whatever's available |
| 19:33 | <GrenBaykre> | Not sure what they mean by SVG as an engine, though. |
| 19:34 | <Velmont> | Sidnicious: No, -- you can write a rendering backend that can render to webgl or to 2d canvas. :-) |
| 19:35 | <hober> | Velmont: there are plenty of apple people here too |
| 19:36 | <GrenBaykre> | Hrm... |
| 19:37 | <Velmont> | hober: Oh, yeah, you make a lot of noise too :] Although I didn't forgot connecting you to Safari. |
| 19:37 | <hober> | :) |
| 19:38 | <Velmont> | uh, s/didn't// |
| 19:51 | <Sidnicious> | Before I forget, I was wondering: why are XMLHTTPRequests specced to only use multipart/form-data when they're sent with FormData? |
| 19:54 | <jgraham> | Sidnicious: I don't know, but what's your use case for something different? |
| 19:55 | <GrenBaykre> | http://www.apple.com/safari/ <-- No trace of Safari for Windows anymore. |
| 19:55 | <GrenBaykre> | So I guess that version is gone |
| 19:55 | <GrenBaykre> | "Only" IE, Firefux, Chrome and Opera to worry about. |
| 19:56 | <MikeSmith> | Hixie, zcorpan, remind me to remind Ms2ger that I made a component for DOM Parsing spec https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=DOM%20Parsing%20and%20Serialization&resolution=--- |
| 19:56 | <Sidnicious> | Shh, they can hear you when you call it that around here. |
| 19:58 | <Sidnicious> | jgraham: I don't have a great one, except that urlencoded is more compact and more widely-supported. The only reason I noticed is that, it turns out, our web framework goes down a "hey, let's expect a file upload" path when it sees a multipart form and 403s the request if a file upload isn't allowed at that URL. |
| 19:59 | <Sidnicious> | (that's definitely a bug on our end, it just made me curious) |
| 20:01 | <Sidnicious> | Since, if the form were sent normally, the UA ordinarily uses urlencoded when a file isn't involved. |
| 20:04 | <jgraham> | MikeSmith: Now I feel left out not to be in your trusted group of reminders :p |
| 20:06 | <jgraham> | TabAtkins: I think your barcode inputmode argument would benefit from an example of how the UI might work if the UA wanted to allow barcode input to any input type but still make use of a special attribute |
| 20:14 | <MikeSmith> | jgraham: I just wasn't sure you weren't away |
| 20:14 | <MikeSmith> | you seem to keep more reasonable hours than zcorpan |
| 20:15 | <Velmont> | I plan on snatching the whole reminding thing away from that trusted tight-knit group by being the reminder! Mohaw!111 |
| 20:31 | <jgraham> | MikeSmith: zcorpan does early mornings, which I don't, but I'm not sure about evenings |
| 20:32 | <MikeSmith> | OK |
| 20:34 | <jgraham> | Stats say I am never here 3am - 8am (if I got the timeoffset right, maybe I didn't?), but zcorpan sometimes is |
| 21:49 | <Subcide> | Hey guys, are there any known problems with the unsubscribe function on the mailing list that anyone's aware of? I'm completely unable to unsubscribe at the moment. |
| 21:55 | <Hixie> | Subcide: should be working... can you walk me through what you're doing and what it did? |
| 21:58 | <Subcide> | Entered my email address on http://lists.whatwg.org/options.cgi/implementors-whatwg.org and clicked unsubscribe. It says an email confirmation will be sent, but I never receive it. |
| 21:58 | <Subcide> | Checked every possible trash, junk, etc. |
| 21:59 | <Subcide> | Password reminders don't get to me either. |
| 22:01 | <Hixie> | what list are you trying to unsubscribe from? |
| 22:01 | <Hixie> | and what e-mail address are you subscribed with? |
| 22:02 | <Subcide> | Damnit, was on the wrong list page. |
| 22:03 | <Subcide> | System probably shouldn't say it's sent an email when the address is invalid for a list ;) |
| 22:04 | <Hixie> | that'll do it :-) |
| 22:04 | <Subcide> | Thanks :) |
| 22:05 | <gsnedders> | Asking someone for help oftens helps you realize you're being silly. :) |
| 22:06 | <Subcide> | As a designer, I blame poor UX ;) |
| 22:06 | <gsnedders> | I do this with doors frequently. I want to know whether to push or pull the door1 |
| 22:06 | <gsnedders> | *! |
| 22:08 | <Subcide> | One day, when Apple make doors, they'll make sense. And only need to be replaced every 3 years or so. |
| 22:18 | <Philip`> | They should avoid the push/pull problem by making circular doors which you spin anticlockwise to open and clockwise to close |
| 22:38 | <zewt> | (then they'll sue everyone else who makes doors) |
| 23:11 | <Hixie> | jesus wept, there is _no_ interop here |
| 23:15 | <gsnedders> | Pretty certain that's too long to be the shortest verse in the Bible. |
| 23:18 | <Hixie> | looks like opera doesn't fire onunload during document.open(), and if you call document.open() in unload, it essentially cancels the unload |
| 23:19 | <gsnedders> | We basically never fire unload. |
| 23:20 | <gsnedders> | Basically, count yourself lucky if you ever get an unload event. :) |
| 23:20 | <Hixie> | firefox just ignores document.open() and document.write() in unload, and doesn't fire onunload for document.open() |
| 23:22 | <Hixie> | chrome doesn't fire onunload during document.open(), but allows document.open() during onunload, though it doesn't cancel the unload |
| 23:22 | <Hixie> | (so you can't see it) |
| 23:23 | <Hixie> | (except in logs) |
| 23:23 | <Hixie> | safari matches chrome |
| 23:23 | <Hixie> | anyone got IE handy? |
| 23:29 | <Hixie> | interesting. chrome _does_ fire onunload for nested iframes during document.open(). |
| 23:29 | <Hixie> | firefox too |
| 23:30 | <Hixie> | (not opera, but that fits gsnedders' point) |
| 23:31 | <Hixie> | safari does too |
| 23:42 | <Hixie> | so i guess the simplest solution here is to make the spec not fire unload events at documents that are currently executing document.open() |
| 23:45 | <Hixie> | chrome doesn't fire beforeunload at all, it seems, in document.open |
| 23:46 | <Hixie> | opera doesn't seem to fire it at all (?) |
| 23:47 | <Hixie> | safari's the same as chrome |
| 23:47 | <Hixie> | firefox fires it, though seems to ignore the result (?) |
| 23:48 | <Hixie> | and doesn't seem to fire it for any frames, nested or otherwise, if the outer frame calls document.open() during beforeunload... |
| 23:49 | <Hixie> | damnit, i really need to test ie here |
| 23:58 | <Hixie> | ok... IE does run beforeunload, but doesn't fire it for subframes... similar to Firefox... but if you cancel it, the previous (outer) document.open() has no effect, it seems |
| 23:58 | <Hixie> | but if you don't cancel it, it doesn't do anything at all? |
| 23:58 | <Hixie> | wtf |
| 23:59 | <Hixie> | it does fire unload for the nested frame |
| 23:59 | <Hixie> | but not the outer frame |