| 03:59 | <MikeSmith> | zewt: http://validator.w3.org/nu/ has an option that lets you persistently filter out any errors or warnings you don't want to see |
| 04:01 | <MikeSmith> | after you check a document, you'll see a "Message filtering" button. If you press that, it'll show you all the messages with show/hide checkboxes |
| 04:02 | <MikeSmith> | but I don't know why it would be giving errors or warnings for non-80 ports |
| 04:24 | <MikeSmith> | OK after looking at the code I find the reason you're seeing that message is because of the library we're currently using for URL checking |
| 04:24 | <MikeSmith> | it has a warning case for this |
| 04:24 | <MikeSmith> | http://jena.sourceforge.net/iri/javadoc/com/hp/hpl/jena/iri/ViolationCodes.html#PORT_SHOULD_NOT_BE_WELL_KNOWN |
| 04:25 | <MikeSmith> | and the reason that library does it is because of http://www.apps.ietf.org/rfc/rfc3986.html#sec-7.2 |
| 04:26 | <MikeSmith> | but I agree there's no reason we should be emitting it from the validator so I'll patch the sources to just drop it on the floor |
| 04:27 | <MikeSmith> | for now |
| 04:28 | <MikeSmith> | but the plan is to replace that library anyway, using smola's library that's based on the current URL standard |
| 04:49 | <MikeSmith> | zewt: fixed https://github.com/validator/syntax/commit/d815de537a86d4334294725d40f077ee2eb0cde9 |
| 04:49 | <MikeSmith> | and pushed to http://validator.w3.org/nu/ |
| 04:51 | <MikeSmith> | Hixie: about ins & del the thing that confused me is that there are UA requirements there but I couldn't see how to actually test that UA conforms to them |
| 05:33 | <MikeSmith> | Hixie: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0100.html doesn't seem like a usability win |
| 05:33 | <MikeSmith> | (message from tkent about input@type=number) |
| 06:18 | <Hixie> | MikeSmith: yeah, there's been a bunch of feedback on type=number that i need to go through |
| 06:19 | <Hixie> | MikeSmith: re ins/del, you mean about parsing datetime? |
| 06:19 | <MikeSmith> | Hixie: yeah, that |
| 06:19 | <Hixie> | MikeSmith: that's mostly just there in case a tool wants to do something with the attribute... but yeah, nobody is required to do anything with it, so it's a bit fluffy |
| 06:19 | <MikeSmith> | ok |
| 06:22 | <Hixie> | Makefile:16: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. |
| 06:22 | <Hixie> | i think the existence of that error message is an insult. |
| 06:26 | <zcorpan> | i often mistakenly type 8 spaces when i forget it's much easier to press that other key in notepad |
| 06:31 | <MikeSmith> | the joys of makefiles |
| 06:31 | <MikeSmith> | I guess to be cool you're supposed to be using something else these days |
| 06:34 | <zcorpan> | implement make in javascript |
| 06:41 | MikeSmith | wonders if zcorpan is traveling or just up early |
| 06:44 | <zcorpan> | the latter, but i'm usually up early when wfh |
| 06:45 | <MikeSmith> | seems to me then you probably don't sleep enough |
| 06:48 | <zcorpan> | around 8h |
| 06:49 | <MikeSmith> | oh |
| 06:50 | <MikeSmith> | well then I guess you do |
| 06:50 | <zcorpan> | not sleeping enough is bad for the health, so i try not to. but sometimes i do anyway if i get stuck reading about interesting things, e.g. health related stuff (ironically) |
| 06:50 | <MikeSmith> | just I still see you on sometimes at like 8am Japan time |
| 06:50 | <MikeSmith> | hah |
| 06:50 | <MikeSmith> | yeah from what I understand you're really supposed to get 8hours of sleep |
| 06:51 | <MikeSmith> | not you personally |
| 06:51 | <MikeSmith> | *we're really supposed to |
| 06:52 | <MikeSmith> | anyway, https://twitter.com/snystrom/status/436387977259139072 and http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired |
| 06:52 | <MikeSmith> | WhatsApp apparently has only 32 engineers |
| 06:53 | <Hixie> | that aquisition boggles my mind |
| 06:54 | <MikeSmith> | buying the users I guess |
| 06:54 | <MikeSmith> | since it's pretty much commodity technology |
| 06:54 | <Hixie> | $35 a user is pretty high. |
| 06:56 | <Hixie> | i wonder how many of their 450 million users have crossed the 1-year mark when they have to pay |
| 06:56 | <Hixie> | anyhoo, i should head to bed. nn. |
| 06:56 | <MikeSmith> | night |
| 09:51 | <annevk-cloud> | https://twitter.com/edds/status/436395256192704512 makes the buy look reasonable… |
| 10:01 | <MikeSmith> | annevk-cloud: canna read that |
| 10:01 | <MikeSmith> | tweets protected |
| 10:14 | <annevk-cloud> | Oh sorry, it compares money per user with other acquisitions such as YouTube |
| 10:14 | <annevk-cloud> | All about the same |
| 10:19 | <MikeSmith> | ok |
| 10:19 | <MikeSmith> | annevk-cloud: so the money per use for whatsapp comes from users paying a subscription fee? |
| 10:19 | <MikeSmith> | *per user |
| 10:20 | <MikeSmith> | oh wait I guess you don't mean that |
| 10:20 | <MikeSmith> | you mean the cost of the acquisition compared to the number of users it brings |
| 10:22 | <MikeSmith> | so for YouTube is must have also been about $35 per user |
| 10:28 | <MikeSmith> | "Skype was acquired by eBay in 2005 for $2.6 billion, working out to roughly $240 per user. Google bought YouTube for $1.65 billion, or nearly $49 per user" |
| 10:29 | <MikeSmith> | http://www.investopedia.com/financial-edge/0412/did-facebook-overpay-for-instagram.aspx |
| 10:33 | <wilhelm> | It's still crazy. Imagine that kind of money being invested into industry, transportation or raw materials instead. You'd get a much quicker return. |
| 10:33 | <MikeSmith> | wow del.icio.us acquisition was $150 per user |
| 10:33 | <MikeSmith> | wilhelm: sure |
| 10:35 | <MikeSmith> | fwiw there's a longer list at https://docs.google.com/spreadsheet/pub?key=0Ag0BxADNLZqgdHdzYVR3a3BoM09jLUxNMC1lMDk2amc |
| 10:38 | <MikeSmith> | anyway in other news I set up https://github.com/whatwg/web-history/blob/master/README.md today |
| 10:39 | <MikeSmith> | contributions encouraged |
| 10:39 | <MikeSmith> | it's pretty thin from 2009 on |
| 10:40 | <MikeSmith> | planning to add more when I can but in the mean time maybe somebody else could add a few things |
| 11:30 | <bhanu> | hi, I want to know what is host, inclusive ancestor and host-including inclusive ancestor, can someone please explain, if possible with example? |
| 11:39 | <MikeSmith> | bhanu: that's in the DOM spec isn't it |
| 11:39 | <MikeSmith> | are you reading some other spec that uses it? |
| 11:40 | <MikeSmith> | http://robert.ocallahan.org/2014/02/3-mile-limit.html is pretty cool |
| 11:40 | <bhanu> | MikeSmith: I couldn't follow it clearly from the spec, so want to understand it |
| 11:41 | <MikeSmith> | bhanu: I guess you want to ask annevk-cloud when he's around |
| 11:41 | <MikeSmith> | or Ms2ger |
| 11:42 | <bhanu> | MikeSmith: I will check with them |
| 11:42 | <Ms2ger> | annevk :) |
| 11:42 | <Ms2ger> | Or dglazkov |
| 11:44 | <bhanu> | Ms2ger: will check with dglazkov since annevk seems to be offline |
| 11:45 | <bhanu> | dglazkov: hi, I couldn't clearly understand the terminologies i.e host, inclusive ancestor and host-including inclusive ancestor |
| 11:45 | <MikeSmith> | dglazkov won't be online for a while yet |
| 11:46 | <MikeSmith> | like 4 hours or so |
| 11:46 | <bhanu> | MikeSmith: oh ok, will check with him later, thanks |
| 11:55 | <zcorpan> | GPHemsley: http://mimesniff.spec.whatwg.org/#parse-a-mime-type compares bytes to code points |
| 12:21 | <MikeSmith> | zcorpan: r? https://critic.hoppipolla.co.uk/r/824 (a few simple validator tests for ins|del@datetime) |
| 12:23 | <zcorpan> | MikeSmith: i was now reminded of "del elements should not cross implied paragraph boundaries." |
| 12:23 | <zcorpan> | which seems like a "fun" thing to check for |
| 12:23 | <MikeSmith> | what that |
| 12:23 | MikeSmith | looks at spec |
| 12:27 | <MikeSmith> | hmm yeah |
| 12:27 | <MikeSmith> | we don't check for that yet |
| 12:27 | <MikeSmith> | I'll raise a bug for it |
| 12:39 | <MikeSmith> | zcorpan: http://bugzilla.validator.nu/show_bug.cgi?id=986 |
| 13:25 | <GPHemsley> | hmm... http://syntax.whatwg.org/ was apparently once a working URL |
| 13:25 | <GPHemsley> | (it is no longer) |
| 13:30 | <GPHemsley> | zcorpan: Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24745 |
| 13:31 | <zcorpan> | MikeSmith: you might reject asking for that review |
| 13:31 | <zcorpan> | er |
| 13:31 | <zcorpan> | regret |
| 13:59 | <MikeSmith> | zcorpan: any review is a good review |
| 14:00 | <MikeSmith> | I don't mind adding more stuff |
| 14:01 | <MikeSmith> | would be nice to get people contributing validator test cases but I don't hold out much hope for that happening, given how hard it is to just get regular tests |
| 14:03 | <zcorpan> | ok i think i'm done now |
| 14:08 | <MikeSmith> | whew |
| 14:09 | <MikeSmith> | heh it's less than it coulda been |
| 14:10 | <MikeSmith> | anyway, maybe we need to separate the tests out to .. somewhere else |
| 14:10 | <MikeSmith> | I mean other then in the dirs for ins/del |
| 14:10 | <MikeSmith> | hmm no, can't do that because datetime for <time> is less restrictive |
| 14:11 | <MikeSmith> | so need to keep them with the elements |
| 14:12 | <zcorpan> | but you could test ins and del in the same page |
| 14:15 | <zcorpan> | i think i'd write the tests in an easy-to-write source format and then generate the html |
| 14:16 | <zcorpan> | <test-name><space><input> |
| 14:17 | <zcorpan> | either two files to separate valid from invalid or a magic line that switches to invalid |
| 14:24 | <MikeSmith> | zcorpan: the limitation I have there is that the test harness is set up to catch only the first error that gets reported |
| 14:24 | <MikeSmith> | I guess I should have it catch all the errors |
| 14:24 | <MikeSmith> | instead |
| 14:25 | <MikeSmith> | that way I could put as many cases as I wanted into each file |
| 14:26 | <zcorpan> | MikeSmith: i meant that a script would generate the html files, one test case per file |
| 14:26 | <MikeSmith> | sure |
| 14:26 | <MikeSmith> | but I mean I have a testrunner in the validator code that automates the tests, and it expects only on error per *novalid.html file |
| 14:27 | <MikeSmith> | or rather it only sees the first error |
| 14:27 | <zcorpan> | yeah, i don't follow why that is a problem |
| 14:27 | <MikeSmith> | oh sorry |
| 14:28 | <MikeSmith> | yeah, I wasn't paying attention to what you actually wrote. Yeah, you're right, it'd be better to generate them from a script |
| 14:29 | <MikeSmith> | python I guess |
| 14:30 | <zcorpan> | i think using the test name in the filename is better than 001 |
| 14:31 | <MikeSmith> | yeah I'm not fond of the numbering thing |
| 14:32 | <MikeSmith> | using the test names makes for longer filenames but it's not like we gain anything from short filenames |
| 14:33 | <MikeSmith> | except shorter URLs but the URLs are pretty long already anyway |
| 16:19 | <foolip> | zcorpan: https://critic.hoppipolla.co.uk/r/822 |
| 16:23 | <zcorpan> | done |
| 16:24 | <TabAtkins> | setTimeout doesn't get clamped when the page is in the background, does it? |
| 16:27 | <jgraham> | No, although it is allowed to per spec |
| 16:32 | <TabAtkins> | Darn, and Chrome definitely does it. Hrm. |
| 16:36 | <gsnedders> | http://imgur.com/ZWzDUdS |
| 16:36 | <jgraham> | TabAtkins: Maybe all browsers do |
| 16:36 | <jgraham> | It is allowed per spec, I just don't recall it being required |
| 16:38 | <jgraham> | Seems like Firefox does too at least |
| 16:43 | <smaug____> | <body></body> seems to create 2 newlines in body |
| 16:43 | <smaug____> | does something require them to be created with just one DOM mutation |
| 17:31 | <MikeSmith> | smaug____: just one newline after the <body> start tag, isn't it? |
| 17:32 | <smaug____> | MikeSmith: 2 |
| 17:32 | <smaug____> | I haven't figured out what in the spec adds any |
| 17:33 | <smaug____> | but Gecko and Blink both seem to insert 2 |
| 17:34 | <MikeSmith> | how do I observe that? |
| 17:34 | <Ms2ger> | Hmm? |
| 17:34 | <Ms2ger> | smaug____, what's the test case? |
| 17:39 | <smaug____> | Ms2ger: https://pastebin.mozilla.org/4348132 |
| 17:39 | <Hixie> | the newline after the </body> |
| 17:39 | <Ms2ger> | Yeah, that |
| 17:39 | <Hixie> | and i bet you have a newline after the </html> |
| 17:40 | <Hixie> | (i tried to fix this, but it turns out there's compat needs or something) |
| 17:40 | <smaug____> | body contains two newlines |
| 17:40 | <smaug____> | and I'm trying to figure out why |
| 17:40 | <Hixie> | all text including whitespace after the </body> end up in the <body> |
| 17:40 | <Hixie> | you have two newlines after the </body> |
| 17:40 | <smaug____> | aha |
| 17:41 | <smaug____> | is it ok for implementation to first insert textnode ("\n"), and then append "\n" to it |
| 17:41 | <Hixie> | it's because "a</body>\nb" has to have a space between the a and the b, and they both have to be in the body |
| 17:41 | <Hixie> | per spec i think all characters are individually appended |
| 17:41 | <smaug____> | and/or is it ok to just create textnode ("\n\n") and append that to body |
| 17:41 | <Hixie> | and then mutation observers coallesce the edits |
| 17:41 | <Hixie> | or something |
| 17:41 | <smaug____> | that is my interpretation too, currently |
| 17:42 | <smaug____> | mutation observer doesn't coalesce character data changes |
| 17:42 | <Hixie> | probably should be allowed to, at least from the parser |
| 17:42 | <Hixie> | though nothing stops the parser from spinning the event loop between each character so it can't be a requirement at the end of the day |
| 17:42 | <Hixie> | (i mean, you don't control when the network gives you bytes) |
| 17:44 | <smaug____> | yup |
| 17:59 | <Hixie> | zcorpan and i have unfortunately non-overlapping hours |
| 18:35 | <zcorpan> | Hixie: here now (for a bit) |
| 18:39 | <Hixie> | zcorpan: now, what was it i wanted to ask... |
| 18:40 | <zcorpan> | Hixie: next time pretend i'm here when i'm not :-P |
| 18:41 | <Hixie> | zcorpan: :-) |
| 18:41 | <Hixie> | i get confused because you leave the channel and i forget you see the logs! :-) |
| 18:42 | <Hixie> | is it bad that my reaction to this thread about P2P web-based games is "use a server" |
| 18:54 | <jcgregorio> | Hixie: yeah, the design seems fragile, if that first player crashes or drops the connection the game is over? |
| 19:06 | <Hixie> | damnit, i just figured out why i needed zcorpan, and he's gone. :-) |
| 19:07 | <Hixie> | jcgregorio: presumably they support handing over to a new peer and doing a master election to pick a new server? |
| 19:08 | <Hixie> | zcorpan: so, we need an event that means "the user agent would like to scroll to this element", which can be canceled so that the author can implement scrolling when it's in a canvas |
| 19:08 | <Hixie> | zcorpan: that sounds like it belongs in CSSOM? maybe? |
| 19:08 | <Hixie> | zcorpan: i'll file a bug |
| 19:15 | <rafaelw> | Hixie: I have no idea what https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c52 means. |
| 19:15 | <jamesr__> | it sounds like he's saying that table sorting has to be special in some way in this scheme |
| 19:15 | <Hixie> | rafaelw: there are several kinds of microtasks, right? |
| 19:15 | <Hixie> | rafaelw: e.g. mutation observers |
| 19:16 | <Hixie> | rafaelw: but also eg. resorting tables, initialising web components, etc |
| 19:16 | <rafaelw> | I'd say there are different types of work done in microtasks (just like tasks) |
| 19:16 | <rafaelw> | yes |
| 19:16 | <Hixie> | rafaelw: ok. call these different types type1, type, type3, etc. |
| 19:16 | <rafaelw> | with you. |
| 19:17 | <jamesr__> | TabAtkins: sounds like this has been covered but rAF never runs in the background (required by spec) and setTimeout is throttled pretty aggressively in lots of browsers (allowed by spec but not required) |
| 19:17 | <Hixie> | rafaelw: if we have a batch of type1 microtasks and a batch of type2 microtasks that all got queued during some especially complicated script, should they all run in the order they were queued, or should they run first all type1, then all type2? |
| 19:17 | <jamesr__> | setTimeout has a "wait by some arbitrary additional UA-determined period of time" step |
| 19:17 | <jamesr__> | Hixie: FIFO |
| 19:17 | <rafaelw> | there's no such thing as a batch of type1 & batch of type2. |
| 19:18 | <rafaelw> | there's just a bunch of microtasks and they get run in FIFO order. |
| 19:18 | <Hixie> | rafaelw: ok so i agree with jamesr__ and i agree with what you just said, but that contradicts what you said in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c47 |
| 19:18 | <Hixie> | assuming the "no" was a response to comment 46 |
| 19:18 | <rafaelw> | brb. |
| 19:19 | <jamesr__> | i think you're trying to read too much into the internals of how mutation observers work |
| 19:20 | <Hixie> | i'm trying to write the internals of how mutation observers work |
| 19:20 | <Hixie> | :-) |
| 19:20 | <jamesr__> | no |
| 19:20 | <jamesr__> | you're trying to write the internals of how microtasks work |
| 19:20 | <Hixie> | well, right now, mutation observers provide me with one hook, which i call, and which runs all the mutation observers |
| 19:21 | <Hixie> | what i'm arguing is that we should change that so that mutation observers provide me with a hook that just runs a single mutation observer. |
| 19:21 | <jamesr__> | and i'm saying you are wrong |
| 19:21 | <jamesr__> | why do you think your proposal is better? |
| 19:21 | <Hixie> | i'm confused |
| 19:21 | <Hixie> | my proposal is what you just said we should do |
| 19:22 | <jamesr__> | this is what comment #25 part 4 is about |
| 19:22 | <jamesr__> | do you understand that bit? |
| 19:22 | <Hixie> | no, i do not understand comment 25 part 4 (see comment 48 where i said as much) |
| 19:22 | <jamesr__> | or comment #28 |
| 19:23 | <Hixie> | comment 28 seems to contradict what you said above in this irc conversation |
| 19:23 | <jamesr__> | no? |
| 19:23 | <Hixie> | then i do not understand one of those two things (or both) |
| 19:24 | <jamesr__> | i think your source of confusion is you are attempting to conflate different units of work into one microtask concept |
| 19:24 | <jamesr__> | not everything is on its own a microtask |
| 19:24 | <Hixie> | i don't know what you mean by "one microtask concept" |
| 19:24 | <jamesr__> | i.e. not every mutation observer callback is a separate independent microtask |
| 19:24 | <Hixie> | ok |
| 19:24 | <Hixie> | that's what i was asking earlier when you said it was :-) |
| 19:24 | <jamesr__> | no, you asked the question badly |
| 19:25 | <Hixie> | i'm happy to concede that |
| 19:25 | <jamesr__> | you asked a question about a bunch of microtasks |
| 19:25 | <Hixie> | let me rephrase the question. |
| 19:25 | <jamesr__> | but if the things you're asking about are not microtasks then the answer will be different |
| 19:25 | <Hixie> | suppose you have a script which causes a bunch of mutations, then causes a table to need to be sorted, then causes a bunch more mutations. |
| 19:25 | <jamesr__> | i would say (1) all microtasks run in FIFO order and (2) some systems, like mutation observers, perform multiple actions within the execution of a single microtask |
| 19:26 | <Hixie> | what should happen when we get to running microtasks in that situation? |
| 19:26 | <jamesr__> | i'm not familiar with the table sorting mechanism. how does it work? |
| 19:26 | <rafaelw> | back. |
| 19:26 | <Hixie> | well, that's up in the air, but the proposal is that when a table needs sorting, a microtask is queued to sort it. |
| 19:26 | <jamesr__> | let's do the example with promises |
| 19:26 | <rafaelw> | hixie: mutation observers have to deliver in order of mutation observer creation time. |
| 19:26 | <jamesr__> | those are simple |
| 19:26 | <rafaelw> | that's already shipped. we can't break compat. |
| 19:27 | <Hixie> | rafaelw: i don't think anyone is disagreeing with that |
| 19:27 | <Hixie> | i have no idea how promises work, but ok |
| 19:27 | <jamesr__> | so let's say you do "d.appendChild(a); d.appendChild(b); promise.resolve(); d.appendChild(c);". the question is what bits enqueue microtasks and what order they fire in, correct? |
| 19:27 | <rafaelw> | what what do you think i was saying in comment 28? |
| 19:28 | <Hixie> | jamesr__: that is a question for which i would like the answer, yes |
| 19:28 | <jamesr__> | (assuming that promise.resolve() enqueues a microtask to run the promise stuff, whatever that is) |
| 19:28 | <rafaelw> | good. so in jame's example: |
| 19:28 | <jamesr__> | i think the answer falls out pretty naturally from 25/28 but let's step through it |
| 19:29 | <rafaelw> | the first appendChild schedules *the* mutation observer microtask to be scheduled. |
| 19:29 | <rafaelw> | all subsequent appendChilds discover that the mutation observer microtask is already scheduled (and don't schedule new microtasks) |
| 19:29 | <rafaelw> | the promise.resolve() schedules a microtask for *only itself*. |
| 19:29 | <Hixie> | so the answer is "c"'s observer fires before the promise? |
| 19:30 | <rafaelw> | yes. |
| 19:30 | <Hixie> | ...why would we want that? |
| 19:30 | <jamesr__> | because that's the only way that makes any sense at all? |
| 19:30 | <Hixie> | why does it make sense? |
| 19:30 | <jamesr__> | keep in mind that the mutation *observer* callback set is not necessary "a, b, c" |
| 19:30 | <jamesr__> | sorry, that was confusing |
| 19:31 | <jamesr__> | the mapping from callbacks for mutations to their originating mutations is not the important part |
| 19:31 | <rafaelw> | i can't argue that's what we want. |
| 19:31 | <Hixie> | what happens if a's callback resolves a promise and then mutates dom node d? |
| 19:31 | <rafaelw> | i'm arguing that's the only choice i know of that works. |
| 19:31 | <jamesr__> | don't think about "a's callback" |
| 19:31 | <jamesr__> | think about "the mutation observer microtask" |
| 19:31 | <Hixie> | what happens if a callback resolves a promise and then mutates dom node d? |
| 19:31 | <rafaelw> | (doesn't break compat with mutation observers) |
| 19:32 | <jamesr__> | if during the mutation observer microtask one of the callbacks mutates the dom, that will enqueue another microtask for mutation observers |
| 19:32 | <rafaelw> | it's actually not even as simple as that. |
| 19:32 | <Hixie> | from the author perspective, and from my perspective as the guy who has to try to spec how this works with spinning the event loop, the atomic unit we care about is the callback, not the microtask, fwiw. |
| 19:32 | <rafaelw> | it's not helpful to ask general questions like that. |
| 19:32 | <jamesr__> | Hixie: that's not a useful perspective to have |
| 19:32 | <rafaelw> | you can only reason about concrete examples. |
| 19:32 | <Hixie> | that's as may be, but it's still my perspective :-) |
| 19:33 | <jamesr__> | and that's why you find this so confusing. think about it in terms of microtasks and it's actually very simple |
| 19:33 | <Ms2ger> | Oh, are we back to telling Hixie he's an idiot? |
| 19:33 | <jamesr__> | there are many ways to think about the problem. some of them make the problem simple, some make it very complicated |
| 19:33 | <jamesr__> | i'm saying if you pick the simple one then you'll be much happier |
| 19:33 | <Hixie> | jamesr__: ok, but if we think about this in terms of microtasks, please explain how we split the microtask when we sping the event loop when a callback calls showModalDialog(). |
| 19:33 | <Hixie> | jamesr__: because without thinking of callbacks, i have no idea how to spec that. |
| 19:34 | <jamesr__> | my vote was that we just throw an exception when calling showModalDialog() |
| 19:34 | <jamesr__> | our usage numbers are pretty darn low for that to begin with |
| 19:34 | <rafaelw> | that's my vote as well. |
| 19:34 | <Hixie> | that was my vote too, but i got outvoted. |
| 19:34 | <rafaelw> | (actually not throw, just silently return) |
| 19:34 | <rafaelw> | abarth liked the idea as well. |
| 19:34 | <jamesr__> | still, it's not that bad |
| 19:34 | <jamesr__> | the mutation observer system has to keep track of which callbacks have run and not run |
| 19:34 | <rafaelw> | i was going to post a patch to blink for exactly this. |
| 19:34 | <Domenic_> | rafaelw: why does a's mutation observer, b's mutation observer, promise stuff, c's mutation observer not work? |
| 19:34 | <jamesr__> | that's not the microtask system's job |
| 19:35 | <Hixie> | rafaelw: unfortunately, my vote counts for squat, and you, jamesr__, and abarth's votes collectively only count as one. |
| 19:35 | <rafaelw> | dom: you're making a false assumption. |
| 19:35 | <Domenic_> | probably :). which one? |
| 19:35 | <rafaelw> | there are observers and there are nodes. it's a many-to-many relationship. |
| 19:35 | <rafaelw> | not a 1;1 |
| 19:35 | <Domenic_> | right, ok. |
| 19:35 | <rafaelw> | ok. i'll post a patch which prevents showModalDialog during a microtaskCheckpoint today. |
| 19:35 | <Hixie> | jamesr__: when you spin the event loop, you have to put a task on the main event loop task queue. What does that task consist of? I was assuming it would consist of just finishing the callback. |
| 19:35 | <rafaelw> | is that helpful? |
| 19:36 | <Domenic_> | but let's pretend we wrote sample code like doSomeStuffToTriggerObserverA(); doSomeStuffToTriggerPromiseB(); doSomeStuffToTriggerObserverC() |
| 19:36 | <Domenic_> | it sounds like that would cause observerA, observerC, promiseB |
| 19:36 | <Domenic_> | becaues you only have a single microtask for all observers |
| 19:36 | <jamesr__> | Hixie: i think i've argued with you before that the way the spec handles spinning the event loop does not match what browsers actually do and is thus not all that helpful |
| 19:37 | <jamesr__> | the behavior i'd actually expect would be that the browser runs the showModalDialog code on top of the callstack of the mutation observer system, then returns, then the mutation observer system takes a look at the state it has after running the showModalDialog and decides what to do |
| 19:37 | <jamesr__> | i.e. the "split a task" thing never happens in reality |
| 19:37 | <jamesr__> | the pending work is sitting on the callstack |
| 19:38 | <Hixie> | jamesr__: so all mutation observers stop during the modal dialog, and then after it returns you get a huge deluge of them? |
| 19:38 | <Domenic_> | why would it not be observerA, promiseB, observerC? |
| 19:38 | <jamesr__> | that's not what i said |
| 19:38 | <jamesr__> | it's reentrant |
| 19:38 | <rafaelw> | dom: in order to reason about these examples you need; creation order of observers, which observers observe which nodes and what order mutations took place/promises resolve. |
| 19:38 | <Hixie> | jamesr__: so the next time we do microtasks, it continues from where it left off? |
| 19:38 | <rafaelw> | jsbin is probably the only way to have the conversation. |
| 19:39 | <Domenic_> | rafaelw: well, ok. but i'll try just asking directly then. why would you batch together all observers, instead of interleaving promises as appropriate? |
| 19:39 | <Domenic_> | above you seemed to imply that was the only thing that worked, but i don't understand why that would be the case |
| 19:40 | <jamesr__> | i think the "as appropriate" bit depends on the actual example |
| 19:40 | <rafaelw> | Hixie; FWIW, this is my frustration as well. It's too hard for me to reason about this when the spec language is so different from what the implementation does. |
| 19:40 | <jamesr__> | Hixie: that depends on what's changed while the modal dialog is up, i would think |
| 19:41 | <rafaelw> | dom: i can only answer that for you by posing a challenge to you: implement microtask delivery as a FIFO queue, and retain the invariant that mutation observers deliver in creation-time order. |
| 19:41 | <Hixie> | jamesr__: well presumably the next time you get a microtask checkpoint is very soon after the dialog went up. at most one regular task can run between the time of the method call and the next time we run microtasks. |
| 19:41 | <Hixie> | jamesr__: so assume that task does nothing, for the sake of argument |
| 19:42 | <Domenic_> | rafaelw: makes sense. the distinction between creation-time order and mutation-order is crucial. i imagine after thinking really hard about this i'll come to the same conclusion as you. |
| 19:42 | <Hixie> | rafaelw: i don't understand how other callbacks being run can in any way affect the order of mutation observer delivery. |
| 19:42 | <rafaelw> | i've got a cake with your name on it if you figure out something better. |
| 19:42 | <rafaelw> | ;-) |
| 19:43 | <Hixie> | rafaelw: other than potentially causing more mutations (which mo callbacks can as well), how can they have any impact at all? |
| 19:43 | <rafaelw> | hixie: what's the current topic? |
| 19:43 | <Hixie> | rafaelw: how other callbacks being run can in any way affect the order of mutation observer delivery. |
| 19:43 | <rafaelw> | and how is that relevant? |
| 19:44 | <Hixie> | isn't that what we've been talking about for the past 40 minutes? |
| 19:45 | <Hixie> | you want to batch the mutation observer callbacks rather than run them one at a time interleaved with other microtask callbacks, right? |
| 19:45 | <rafaelw> | i think we need to do this differently. |
| 19:46 | <Hixie> | every time i ask a question you try to change the approach, it's making it very hard for me to improve my understanding. |
| 19:46 | <rafaelw> | how about you propose an approach and i'll try to provide a case which doesn't retain creation-order delivery for mutation observers. |
| 19:46 | <Hixie> | ok |
| 19:46 | <Hixie> | my approach is this: |
| 19:46 | <Hixie> | when it's time to run microtasks, run these steps: |
| 19:46 | <Hixie> | 1. if one or more mutation observers need to run, run one. |
| 19:47 | <Hixie> | 2. run another microtask, in the order they were queued. |
| 19:47 | <Hixie> | 3. goto 1 unless there's no more work to be done. |
| 19:47 | <rafaelw> | ok. what you've proposed is not a fifo queue. |
| 19:47 | <rafaelw> | it's a priority queue. |
| 19:48 | <Hixie> | (this is not a final proposal, i'm just trying to work out if it would work, so that i can figure out the problem you're describing) |
| 19:48 | <rafaelw> | yes. it's possible to retain creation-time ordering with this approach. |
| 19:48 | <Hixie> | ok |
| 19:48 | <Hixie> | so, new approach: |
| 19:49 | <Hixie> | whenever a mutation occurs, queue a microtask for each observer that it could fire, ignoring all previously queued microtasks. |
| 19:50 | <Hixie> | when a mutation observer microtask comes up, run the callback that applies, taking into account all subsequently queued microtasks, and remove any subsequently queued microtasks that no longer apply because we handled them here. |
| 19:50 | <Hixie> | microtask handling consists of: |
| 19:50 | <Hixie> | 1. run the oldest queued microtask. |
| 19:50 | <Hixie> | 2. goto 1 unless there's no more queued work. |
| 19:52 | <rafaelw> | thinking |
| 19:52 | <jamesr__> | IOW, have microtask deliver be the same but redefine the mutation observer microtask's work to be something else. that seems basically equivalent to #25 assuming that the "taking into account all subsequently" also takes care of the reordering that would happen to satisfy the mutation observer constraints |
| 19:52 | <Hixie> | can you elaborate on the reordering thing? |
| 19:52 | <jamesr__> | trivial mapping back to the comment 25 proposal: the "taking into account" step includes generating all the other callbacks needed to preserver order and firing them |
| 19:53 | <jamesr__> | and cancelling all other mutation-related microtasks |
| 19:53 | <Hixie> | my aim here is for each microtask to only ever fire one callback |
| 19:55 | <rafaelw> | can you explain: "taking into account all subsequently queued microtasks, and remove any subsequently queued microtasks that no longer apply because we handled them here" |
| 19:57 | <rafaelw> | hixie: can i re-state this approach as follows: |
| 19:57 | <rafaelw> | -every time an observed node is mutated, schedule a new mutation observer microtask |
| 19:58 | <rafaelw> | -all mutation observer callbacks do the same thing: |
| 19:58 | <rafaelw> | -find the observer with the oldest creation time and deliver all pending records to it |
| 19:58 | <Hixie> | does "deliver all pending records" mean more than one callback? |
| 19:59 | <aklein> | Hixie: no, that's a single callback (the callback takes an array of MutationRecords) |
| 19:59 | <rafaelw> | it doesn't. it means one callback. |
| 19:59 | <Hixie> | k |
| 19:59 | <Hixie> | wouldn't you need to schedule one of these per observer per mutation? |
| 19:59 | <Hixie> | per relevant observer, at least |
| 20:00 | <rafaelw> | yes. |
| 20:00 | <rafaelw> | sorry. you are right. |
| 20:00 | <jamesr__> | fwiw the Object.observe deliverChangeRecords() algorithm invokes a callback multiple times (if i've found the right proposal) |
| 20:00 | <rafaelw> | you'd need to schedule a microtask for each observer which had a mutation record added to it's pending queue. |
| 20:00 | jamesr__ | is off to lunch, back soon |
| 20:00 | <rafaelw> | jamesr__: correct. |
| 20:00 | <Hixie> | right |
| 20:01 | <Hixie> | as far as dom mutation observers go, i think what you describe is what i meant, yes |
| 20:01 | <rafaelw> | hixie: have i correctly restated your proposal? |
| 20:01 | <rafaelw> | ok, so this actually does break compat with the current ordering behavior (though it does retain the creation-time invariant). |
| 20:02 | <Hixie> | oh ok, good. how so? |
| 20:02 | <rafaelw> | the way ordering is spec works like this: |
| 20:02 | <rafaelw> | when mutation observers deliver |
| 20:02 | <rafaelw> | take the set of observers whcih pending change records |
| 20:02 | <rafaelw> | order that set by creation time |
| 20:03 | <rafaelw> | deliver to that set in creation order |
| 20:03 | <rafaelw> | when you are done, if there are new observers pending delivery, start over. |
| 20:03 | <rafaelw> | so basically, you've created a *strict* priority queue for mutation observers, but unfortunately, that's not what is implemented. |
| 20:04 | <rafaelw> | (sorry. i have to go to lunch and i'm out tomorrow. we can pick this up next week). |
| 20:04 | <Hixie> | what you describe doesn't quite seem to match what i'm reading on dom.spec.whatwg.org |
| 20:04 | <rafaelw> | it seems like you're trying really hard to have 1-1 microtask-callback. |
| 20:04 | <rafaelw> | this is going to be hard. |
| 20:04 | <rafaelw> | custom element callbacks present a different set of ordering requirements |
| 20:04 | <Hixie> | the alternative is harder, if we have showModalDialog() :-) |
| 20:05 | <Hixie> | if you could convince the other vendors to kill showModalDialog(), this would make our lives way easier |
| 20:05 | <Hixie> | even just kill showModalDialog() inside microtasks |
| 20:05 | <Hixie> | it's the only remaining spin-the-event-loop callsite that can be invoked in a microtask |
| 20:05 | <Hixie> | anyway, we'll carry on next week, sure |
| 20:06 | <aklein> | Hixie: re: the dom spec, which part of the algorithm at http://dom.spec.whatwg.org/#concept-mo-invoke doesn't match Rafael's explanation? |
| 20:07 | <Hixie> | MikeSmith: if we go with that proposal i suggested, then that IBM.* issue would be much simpler -- they would just click "add as proprietary value" each time they validated a document with a new value, and it'd never come up again |
| 20:07 | <aklein> | we worked pretty closely with annevk to get it to match up with the implementation (after several go-rounds that read differently than the implementation) |
| 20:08 | <Hixie> | aklein: if i understand rafaelw's description, you first make a list of observers and their records, and then call their callbacks; the spec, though, just makes a list of observers, then for each one gets the records and calls the callback. |
| 20:08 | <Hixie> | aklein: so if you have observers A and B, and they each have a record, and A's callback adds a record to B, the next thing that happens is B's callback with two records |
| 20:08 | <Hixie> | aklein: as opposed to the next thing being B having two separate callbacks |
| 20:09 | <aklein> | Hixie: I think you just misunderstood rafaelw (or he misspoke). in the case you've outlined, A is first called with a single record, and then B is called (once) with two records |
| 20:10 | <aklein> | would you agree that's what the spec says? that's what our implementation does |
| 20:10 | <Hixie> | i agree that the spec calls B with two records at once in that case |
| 20:10 | <MikeSmith> | Hixie: yeah except that everybody who used the validator would click that button every time they checked a page that had unregistered meta@name values and eventually we'd have a gazillion values registereed and that state would be pretty much just like making any arbitary string valid |
| 20:10 | <Hixie> | aklein: but so how is what i proposed earlier different? |
| 20:10 | <aklein> | Hixie: for this case, it's the same |
| 20:10 | <Hixie> | MikeSmith: except that the validator would say "valid! (uses proprietary values)" instead of just "valid!" |
| 20:10 | <aklein> | but imagine that A causes a mutation that adds another record to A's queue |
| 20:11 | <Hixie> | MikeSmith: and typos would get caught |
| 20:11 | <aklein> | Hixie: in that case, you and the spec differ. the spec says to call A with one record, then B with one record, then A again |
| 20:11 | <MikeSmith> | Hixie: typos would get registered too |
| 20:11 | <aklein> | whereas your ordering would be A (one record), A (one record), B (one record) |
| 20:11 | <Hixie> | MikeSmith: why? |
| 20:12 | <Hixie> | aklein: ah, yeah, i guess that's a difference between my original proposal and rafaelw's restatement |
| 20:12 | <Hixie> | aklein: i meant each microtask to be designated a specific observer whose's queue should be flushed. |
| 20:12 | <MikeSmith> | because somebody would click "register" when their document had a typoed value that generated an error slash "do you want to register me?" message |
| 20:13 | <aklein> | Hixie: that's why rafael asked what you meant by "taking into account other queued microtasks" |
| 20:13 | <Hixie> | aklein: but i guess that would mean my proposal misses the case of A having one record, B having none, and A's callback adding to A and B |
| 20:13 | <Hixie> | aklein: since per spec today you'd want A, B, A, but i'd give A, A, B |
| 20:13 | <Hixie> | aklein: and that can't be fixed easily since B might not exist when the first record is queued |
| 20:13 | <Hixie> | interesting |
| 20:14 | <aklein> | Hixie: oh, I think I may begin to understand what you were proposing |
| 20:14 | <Hixie> | MikeSmith: well that's why in my proposal we have "did you mean /author/?" and so on. at the end of the day, if people are validating but don't care about the errors, the validator is pointless. |
| 20:15 | <Hixie> | MikeSmith: we could just provide a trivial implementation that just said "it's valid! pat pat!" |
| 20:15 | <aklein> | Hixie: were you saying that you enqueue tasks for all possible observers whenever a mutation occurs? even ones for which no records were enqueued by that mutation? |
| 20:15 | <Hixie> | MikeSmith: i have to believe that validator users at least want to know about errors |
| 20:15 | <Hixie> | aklein: i wasn't, but then i was, but then i realised that wouldn't work because mutation observers might be created later |
| 20:16 | <Hixie> | MikeSmith: (note that in my proposal there was also the back-end review process where typos would get flagged as permanently not ok) |
| 20:16 | <Hixie> | MikeSmith: (so at least eventually they'd get flagged) |
| 20:16 | <Hixie> | MikeSmith: (with a useful message) |
| 20:18 | <MikeSmith> | yeah I understand all that. I have a half-finished draft of a reply to you on that thread that I will try to finish soon. In the mean time it would still be good to try to get hsivonen to chime in. |
| 20:18 | <MikeSmith> | for now I gotta get some sleep |
| 20:18 | <Hixie> | yeah i wish i knew what henri wanted here |
| 20:18 | <MikeSmith> | yeah |
| 20:18 | <Hixie> | aklein: i guess we really do want two kinds of microtasks, those that are trivial with at most one callback, which can be handled easily by the current prose, and then the ones for mutation observers which would need to do special work for each of their callbacks |
| 20:19 | <Hixie> | aklein: assuming we can't just break compat and go to just a queued model, anyway |
| 20:21 | <aklein> | Hixie: note that custom elements also have special ordering constraints, mutation observers aren't the only one |
| 20:22 | <aklein> | Hixie: it's definitely unclear to me how much the web depends on the ordering here |
| 20:22 | <aklein> | but without the specified creation-time ordering, we worried that implementations might end up with different orderings due to DOM implementation details |
| 20:23 | <aklein> | (e.g., the ordering might be dependent on hash table implementations) |
| 20:24 | <Hixie> | yeah |
| 21:00 | <jamesr__> | btw, it looks like showModalDialog use is low enough were we might be able to just straight kill it |
| 21:05 | <Hixie> | jamesr__: i certainly would support that! |
| 21:06 | <Hixie> | jamesr__: historically all attempts at convincing other vendors of this have been unsuccessful :-( |
| 22:00 | <Hixie> | k |
| 22:11 | <Hixie> | i wish there was a way in bugzilla to select bugs for which i was not the last person who commented |
| 22:24 | <Hixie> | anyone got IE around who can tell me what the two frames in this test say for HTTP_REFERER ? |
| 22:24 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2830 |
| 22:25 | <Hixie> | also, does safari just not send referers for iframes or something? |
| 22:26 | <Hixie> | or actually, try http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2831 |
| 22:26 | <Hixie> | it has a third frame at the bottom |
| 22:26 | <Hixie> | (very bottom of the dom viewer) |
| 22:27 | <Hixie> | if you have results for that test, the bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24613 |
| 22:52 | <Domenic_> | What other things do custom elements not explain? Form submission is an easy and obvious one, but what else can native elements do that custom elements can't? |
| 22:54 | <Hixie> | <input> in general is pretty hard to explain |
| 22:54 | <Hixie> | e.g. the way it impacts <form>.elements |
| 22:54 | <Hixie> | the way you can change hte type="" attribute |
| 22:54 | <Hixie> | the way type=file lets you access the file system |
| 22:54 | <Hixie> | the way it interacts with <label> |
| 23:01 | <Domenic_> | yeah jonas was saying how <form>.elements is screwy |
| 23:02 | <Domenic_> | what is tricky about the interaction with label? |
| 23:15 | <Hixie> | Domenic_: nothing particularly tricky, but <label> doesn't know about custom elements, so it won't do anything useful with them |
| 23:16 | <Hixie> | Domenic_: note that i think form submission is kind of a red herring. With things like web sockets, it's not as important to actually submit anything. It's more interesting to be in form.elements and the like. |
| 23:16 | <Domenic_> | ah right |
| 23:17 | <Hixie> | hober: it's cute how we're finally discussing these things that i had specced in xbl2 and web control 2.0 back in 2004 :-P |
| 23:22 | <hober> | Hixie: right? |
| 23:22 | <Hixie> | i wish it had gotten more traction back then |
| 23:23 | <Hixie> | oh well |
| 23:23 | <Hixie> | i didn't push it much either |