| 01:07 | <heycam> | Hixie, my irc bouncer sometimes loses track of whether it has marked me away when I disconnect from it abnormally |
| 01:07 | <Hixie> | hehe |
| 01:08 | <Hixie> | heycam: for the incumbent script thing |
| 01:09 | <Hixie> | heycam: i'd like this algorithm to be invoked when you call a callback: http://whatwg.org/html#jump-to-a-code-entry-point |
| 01:09 | heycam | looks |
| 01:09 | <Hixie> | heycam: it handles things like script getting disabled, the document no longer being active, and marking the entry script |
| 01:09 | <Hixie> | heycam: and invoking microtasks, etc |
| 01:10 | <Hixie> | heycam: you got any ideas on how to hook this up? |
| 01:10 | <heycam> | Hixie, ah so you'll handle all the pushing and popping to the stack |
| 01:12 | <heycam> | Hixie, so I don't really understand the relationship between the Function object that I have in my callback invoking algorithm and the "code entry-point" |
| 01:13 | <Hixie> | yeah, there's no relationship (any more, i broke that yesterday when i realised i never invoked callbacks, before realising you did and we needed this still) |
| 01:13 | <Hixie> | but we can fix that by renaming the algorithm or something |
| 01:13 | <heycam> | Hixie, actually, do you want Web IDL to push/pop the incumbent script stack or not? |
| 01:13 | <Hixie> | heycam: well, you still have to push when you're invoking things that aren't script |
| 01:13 | <Hixie> | e.g. in setTimeout(window.alert, 100, s) |
| 01:14 | <Hixie> | when you call window.alert |
| 01:14 | <heycam> | I see |
| 01:14 | <heycam> | but I think I need to push/pop even for Function objects that come from a script, because Web IDL has the stashed away script to push/pop |
| 01:14 | <heycam> | can't just call in to "jump to a code entry-point", unless I pass that script in to that algorithm |
| 01:15 | <heycam> | or is that what "for a script" means |
| 01:15 | <heycam> | in "When a user agent is to jump to a code entry-point for a script, ..." |
| 01:16 | <Hixie> | yeah, this will need some work on both ends |
| 01:16 | <Hixie> | (i'm not actually able to work right now, just wanted to give you a brain dump since you were online) |
| 01:17 | <heycam> | ok |
| 01:17 | <heycam> | so if I can just pass in to you the Function object, the arguments to pass to it (and the this value to use), and the script I've stashed away, that should work |
| 01:18 | <Hixie> | sounds good to me. pass it to a new algorithm and i'll hook it all up on monday. |
| 01:19 | <heycam> | then I can remove the pushing/popping that I do |
| 01:35 | <Hixie> | heycam: just make sure you still do it when the thing you're calling is a host thingy and not a script |
| 01:36 | <heycam> | Hixie, ok. the two shouldn't be handled differently in Web IDL currently. |
| 01:46 | <Hixie> | heycam: i mean, still do it on your side (not call into the html algorithm) |
| 01:47 | <heycam> | Hixie, oh ok. so in that case I should be the one invoking [[Call]]? but for Function objects from a script, your algorithm will invoke [[Call]]? |
| 01:48 | <Hixie> | well my algorithm has no idea how to handle "call window.alert()", as in the setTimeout(window.alert, 100, s) case, where the callback is a host thing |
| 01:49 | <heycam> | hmm |
| 01:49 | <heycam> | what's the difference? does the step 4 you've currently got there do anything special? |
| 01:49 | <Hixie> | well there's no script |
| 01:50 | <Hixie> | i guess that's what you meant by you have a script and an entry point, though, hm |
| 01:50 | <heycam> | but does step 4 just mean "invoke [[Call]]"? |
| 01:50 | <Hixie> | yeah i guess if you force feed me the info i need, that works |
| 01:50 | <Hixie> | i've no idea what step 4 really means |
| 01:50 | <heycam> | heh |
| 01:50 | <Hixie> | it's trying to vaguely be language-agnostic |
| 01:50 | <heycam> | ah |
| 01:51 | <Hixie> | though that may be a lost cause |
| 01:51 | <Hixie> | i think we're likely to see a return to people caring about that shortly, though |
| 01:51 | <Hixie> | like, in the coming years |
| 01:51 | <Hixie> | with asm.js and so forth |
| 01:51 | <heycam> | we'll see I guess |
| 01:51 | <heycam> | ok I'll write some text and I'll send you an email |
| 01:52 | <heycam> | oh one thing |
| 01:52 | <heycam> | this algorithm can abort in certain situations where it can't call the function |
| 01:52 | <heycam> | on the Web IDL side, I'm expecting to return a value of a particular Web IDL type. for example if it's a callback function with a particular return type |
| 01:53 | <heycam> | so in that situation I can't just return nothing. feels like I should be throwing an exception in that case. |
| 01:54 | <heycam> | though not sure what exception it should be |
| 01:54 | <Hixie> | only if the script is disabled, right? |
| 01:54 | <Hixie> | what would you do with the exception? |
| 01:54 | <heycam> | propagate it out? |
| 01:54 | <Hixie> | to what? if script is disabled... |
| 01:55 | <heycam> | is script being disabled the only situation where you don't invoke callbacks like this? |
| 01:55 | <Hixie> | the document not being active |
| 01:55 | <Hixie> | i think that's it, no? |
| 01:55 | <Hixie> | i'd just treat the return value as "void" |
| 01:55 | <Hixie> | and pretend it ran a no-op |
| 01:56 | <heycam> | if my callback is a `callback Something = Node ();` |
| 01:57 | <heycam> | I guess I could pretend the function returned undefined, try to convert that, and throw as a result |
| 01:57 | <heycam> | but as you say this might not be user visible anyway |
| 01:57 | <Hixie> | i would treat it as if the script had been function () { } |
| 01:57 | <heycam> | ok |
| 01:59 | <heycam> | so when you do these preparatory steps of checking if scripting is disabled for the script's browsing context, is that not for the script that's currently on the top of the stack, but the script the Function object actually comes from? |
| 01:59 | <heycam> | does it make sense if you do `setTimeout(window.alert, …)` to look at the incumbent script that was associated with window.alert, when you passed it in as a callback? |
| 01:59 | <Hixie> | it's for the script you're about to run |
| 02:00 | <Hixie> | in that particular case, i doubt it matters exactly who you're checking |
| 02:00 | <heycam> | hmm |
| 02:00 | <Hixie> | oh, it should matter actually |
| 02:00 | <Hixie> | it should be the script that called window.setTimeout() |
| 02:00 | <heycam> | aha |
| 02:01 | <Hixie> | though i think for timeout we actually already have mechanisms in place to stall them if the window is not active |
| 02:01 | <Hixie> | so it doesn't much matter |
| 02:02 | <heycam> | would that be ok in general though? do these preparatory steps on the script that's on top of the stack, if it's a host object thing, and the actual script the Function object is from if it's a user thing? |
| 02:14 | <Hixie> | i guess? |
| 02:14 | <Hixie> | maybe we don't even do them for host things |
| 02:17 | <heycam> | the step 3 where we push on to the incumbent script stack, is it right that we push the actual script the Function object came from, if it is a user thing, but we need to push the "whatever was at the top of the stack at the time we passed in the callback" script for a host thing? |
| 02:17 | <heycam> | I think I got that bit wrong with my initial edits |
| 02:23 | <Hixie> | i'm not sure |
| 02:23 | <Hixie> | i do know that if it's not an author script, we don't want to be setting the candidate entry script flag thing |
| 02:23 | <Hixie> | though it may not matter... |
| 02:23 | <Hixie> | i don't know |
| 02:23 | <Hixie> | sorry dude, not awake right now :-) |
| 02:23 | <heycam> | heh fair enough ;) |
| 02:24 | heycam | has no idea what candidate entry script flag is for |
| 02:24 | <heycam> | anyway, I'll write something up and you can look at it later |
| 02:25 | <Hixie> | it sets the entry script, which is used for security |
| 05:35 | <treehau55> | e |
| 09:28 | <MikeSmith> | Hixie: what's the rationale for the http://html5.org/r/8109 change? |
| 09:29 | <heycam> | (it's also got a typo) |
| 09:30 | <Ms2ger> | MikeSmith, "Requiring the Encoding Standard preferred name is too strict for no good reason" thread on whatwg? |
| 09:31 | <MikeSmith> | Ms2ger: oh thanks |
| 09:31 | <Ms2ger> | (And the aone typo is fixed) |
| 09:31 | <MikeSmith> | oK |
| 09:31 | MikeSmith | is way behind on reading list mail |
| 09:32 | <MikeSmith> | in other news http://html5.org/r/8108 is a pretty significant implementation change |
| 09:33 | <MikeSmith> | would be good to hear what hsivonen_ thinks of it |
| 09:33 | <MikeSmith> | Ms2ger: think I should open a mozilla bug for that one? |
| 09:34 | <MikeSmith> | against the HTML parse |
| 09:34 | <MikeSmith> | *parser |
| 09:34 | <Ms2ger> | MikeSmith, that would probably be good |
| 09:37 | <MikeSmith> | ok |
| 09:37 | <Ms2ger> | Though I believe there's a bunch of other parser changes too |
| 09:40 | <MikeSmith> | oh? |
| 09:40 | <MikeSmith> | ah yeah |
| 09:44 | <MikeSmith> | Ms2ger: just raised https://bugzilla.mozilla.org/show_bug.cgi?id=901319 for the AAA change |
| 09:44 | <Ms2ger> | Thanks |
| 15:10 | <zewt> | okay this is like the third site i've seen that tries to keep me from pasting my email address in |
| 15:10 | <zewt> | i don't know why but i'm still surprised by the imaginative ways people are complete idiots |
| 16:18 | <zewt> | there's a fascinating one: submitting a form on a website broke because I had a newline in a textarea, with a "JSON.parse: bad control character in string literal" error |
| 16:18 | <zewt> | so I can only guess that somebody out there is actually constructing JSON by going '"' + text + '"' |
| 16:28 | <gsnedders> | Surprise level: 0. |
| 16:29 | <zewt> | yep. heh |
| 19:15 | <teoss> | there must be space between doctype and html element? |
| 19:20 | <gsnedders> | teoss: No, there's no need. But note that the DOCTYPE is the whole string, "<!doctype html>"; any html start tag must follow that. |
| 19:21 | <teoss> | yep thanks gsnedders but here I think it says I must put white space? http://www.w3.org/html/wg/drafts/html/master/syntax.html#syntax-doctype |
| 19:23 | <gsnedders> | teoss: No, it says nothing about what comes after the DOCTYPE, just the syntax of the DOCTYPE itself. |
| 19:28 | <teoss> | yes sorry gsnedders I ment affter html in doctype there must be space? like this: <!doctype html > or it can like this> <!doctype html> ? |
| 19:29 | <gsnedders> | teoss: As I said, there's no html element there. And the spec says "Zero or more space characters" after the "html", so zero space characters is fine. |
| 19:30 | <teoss> | ah yes zero or more lol |
| 19:30 | <teoss> | ok thanks and sorry |
| 19:30 | <teoss> | gsnedders, can I put paragraph in paragraph? |
| 19:33 | <gsnedders> | teoss: Only in XHTML, though why do you want to? |
| 23:01 | <teoss> | web page is valid without head and body elements? |