| 00:45 | <heycam> | Hixie, no there's no need to put [Exposed] on the ancestors of a global interface |
| 00:45 | <heycam> | Hixie, I should write something about "implements" and [Exposed], though, that's not handled currently |
| 00:45 | <heycam> | Hixie, though I do handle partial interfaces |
| 00:46 | <heycam> | Hixie, if [Exposed] is on a [NoInterfaceObject], then it should be just like if you used a partial interface with [Exposed] on it |
| 00:47 | <heycam> | or maybe it should be on the implements statement, as you say |
| 03:02 | <othermaciej> | annevk-cloud: is there a test suite anywhere for your url spec? |
| 03:07 | <Domenic_> | annevk-cloud: not written down. CancellablePromise is the most prominent. |
| 03:13 | <MikeSmith> | othermaciej: https://github.com/w3c/web-platform-tests/tree/master/url |
| 03:18 | <MikeSmith> | othermaciej: and served at http://w3c-test.org/web-platform-tests/master/url/a-element.html |
| 03:24 | <othermaciej> | MikeSmith: thanks! |
| 03:24 | <MikeSmith> | cheers |
| 03:25 | <othermaciej> | I'm about to implement the URL interface, maybe I can tweak the A element tests to apply to URL |
| 03:26 | <othermaciej> | I wonder if any of these tests check mutation of URL components? |
| 03:29 | <MikeSmith> | othermaciej: I think they do not |
| 03:38 | <Streusel> | LOGIN Streusel 1234 |
| 03:38 | <Streusel> | whoops |
| 03:38 | <Streusel> | awh well |
| 04:17 | <Fernandos> | hi |
| 04:20 | <Fernandos> | Can <section>, <article> and <aside> be a parent of <main> and is that meaningful (semantic)? <main class="row"> <aside>my-sidebar</aside><section>my-widescreen-section</section><article>my-content</article></main> |
| 04:27 | <SimonSapin> | annevk-cloud: 1024, you bytes for encoding detection? |
| 05:21 | <Domenic_> | Fernandos: that shows them being a child of main, not a parent. |
| 07:39 | <SteveF> | Fernandos: see http://html5doctor.com/the-main-element/ |
| 07:52 | Ms2ger | wonders why some people call hsivonen "Henry" |
| 07:57 | MikeSmith | wonders why some people call hsivonen "Onry" |
| 08:17 | <TabAtkins> | Ms2ger: Because "Henri" is a rare spelling in America? |
| 08:22 | <othermaciej> | "Onry" is how "Henri" is pronounced in French, with English speakers have probably heard more often than presumably the Finnish version |
| 08:25 | <zcorpan> | Ms2ger: how would https://critic.hoppipolla.co.uk/r/56 be done with testharness-in-workers support? |
| 08:25 | <zcorpan> | othermaciej: URL interface probably needs a different set of tests |
| 08:26 | <zcorpan> | othermaciej: that testsuite is primarily about parsing/resolving |
| 08:27 | <othermaciej> | yeah, I can see that |
| 08:27 | <othermaciej> | will try to make my own |
| 08:28 | <MikeSmith> | othermaciej: yeah I was just being sportive. Having some sport with the name. Like the first time plh told me about Hungry Mother in Cambridge and I was searching google maps for "Angry Mother" to find the location |
| 08:28 | <zcorpan> | you get 5 bounty points for making a web-platform-tests pull request :-) |
| 08:29 | <MikeSmith> | we need proper webidlharness.js-based tests for the URL interface I guess |
| 08:29 | <hsivonen> | I once almost missed a telecon that involved the organizer calling me and asking if I was [American approximation of French pronunciation of Henri] |
| 08:30 | <hsivonen> | OTOH, in Starbucks du Louvre, I said my name was Henri (pronounce the French way) and the American kid working at Starbucks in France wrote "Harry" on the cup |
| 08:30 | <hsivonen> | can't win |
| 08:30 | <zcorpan> | MikeSmith: yeah, but that's not enough |
| 08:30 | <Ms2ger> | zcorpan, 10 for reviewing one? :): |
| 08:30 | <MikeSmith> | hsivonen: hah |
| 08:31 | <zcorpan> | Ms2ger: sure |
| 08:32 | Ms2ger | looks how https://critic.hoppipolla.co.uk/r/56 works |
| 08:33 | <MikeSmith> | zcorpan: well we need that at least. though it wouldn't be very satisfying to run unless Gecko already supports the interface |
| 08:34 | zcorpan | gets his shield while Ms2ger discovers how horrible that code is |
| 08:34 | <Ms2ger> | Heh |
| 08:34 | <Ms2ger> | You've got your shield now? :) |
| 08:34 | <zcorpan> | hold on... yep ok |
| 08:35 | <Ms2ger> | You're testing postMessage, so I don't see how it would work with writing only one side |
| 08:36 | <zcorpan> | right |
| 08:36 | <Ms2ger> | So "like this" |
| 08:37 | <hsivonen> | Ms2ger: FWIW, in English, I introduce myself the way "Henry" is pronounced in English |
| 08:37 | <zcorpan> | Ms2ger: ok |
| 08:38 | <Ms2ger> | hsivonen, now I wonder if I've been mispronouncing Henry, Henri, or both :) |
| 08:42 | <zcorpan> | Ms2ger: i was thinking about introducing a way to do more assertions of a test in a worker. but maybe it'd be clearer to have two separate tests for the two contexts. dunno, but it would be nice to be able to use real assertions somehow |
| 08:44 | <Ms2ger> | So making steps on one test in both contexts? That sounds somewhat painful |
| 08:46 | Ms2ger | will think about it some more |
| 08:52 | <hsivonen> | Oh great. The SVG WG has introduced a new camel-case element that's not in the HTML parsing spec: feDropShadow |
| 08:53 | <Ms2ger> | Hey, you could be dealing with the geolocation wg |
| 08:54 | <hsivonen> | Ms2ger: is geolocation still active? |
| 08:54 | <Ms2ger> | Apparently "no, fuck your comments" |
| 09:05 | <zcorpan> | are javascript RegExp .sticky and .unicode implemented? |
| 09:06 | <zcorpan> | hsivonen: they promised they wouldn't do that iirc |
| 09:25 | <hsivonen> | SimonSapin: thanks for https://dvcs.w3.org/hg/csswg/rev/8dd698785f16 |
| 09:47 | <hsivonen> | how long until this gets attributed to the WHATWG: http://wiki.whatwg.org/wiki/Internet_Encrypted_Media_Extensions ? |
| 10:12 | <zcorpan> | BREAKING NEWS: WHATWG PUTS ITS WEIGHT BEHIND DRM AND HIXIE EATS KITTENS |
| 10:13 | <hsivonen> | http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html says to look at https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html which gives an error |
| 10:15 | hsivonen | finds https://dvcs.w3.org/hg/FXTF/raw-file/e1ae5deb9fa8/filters/index.html |
| 10:29 | <darobin> | hsivonen: the answer is, not long, not long at all... https://twitter.com/johnfoliot/status/428039862097559552 |
| 10:30 | <Ms2ger> | An unhelpful comment from John Foliot? Count me surprised. |
| 10:32 | <hsivonen> | At least JF is right about that the suggestion on the wiki page being misguided. |
| 10:35 | <zcorpan> | SimonSapin: hsivonen: wait, why is the @charset change good? won't the label fail to match if it contains whitespace anyway? |
| 10:37 | <hsivonen> | maybe the spec has changed in other ways, since I last read it |
| 10:37 | hsivonen | looks |
| 10:38 | <zcorpan> | hmm http://encoding.spec.whatwg.org/#concept-encoding-get does trim whitespace. wonder why |
| 10:39 | <hsivonen> | zcorpan: since when has the spec constrained the values of XX to between 0x23 and 0x7E? |
| 10:39 | <hsivonen> | and yeah, 19 bytes is much better than 1024 |
| 10:39 | <zcorpan> | dunno |
| 10:39 | <hsivonen> | despite Gecko using 1024 now |
| 10:40 | <hsivonen> | or Gecko using 1024 last time I looked |
| 10:42 | <zcorpan> | annevk-cloud: see above |
| 10:44 | <jgraham> | FWIW annevk-cloud has taken to using a pseudonym when in situations that casually require a name (e.g. ordering food) in the UK |
| 10:45 | Ms2ger | wonders which |
| 10:46 | <zcorpan> | hsivonen: s/19/31/ |
| 10:51 | <zcorpan> | http://www.behindthename.com/names/extra.php?terms=anne&extra=s&gender=both |
| 10:52 | <jgraham> | zcorpan: Not "Amy" |
| 10:55 | <zcorpan> | oh the url didn't update when i changed the filter. i meant to filter for male english names |
| 12:01 | <hsivonen> | zcorpan: do you have a reference to whatever the SVG WG agreed to regarding camelCasing? |
| 12:02 | <MikeSmith> | hsivonen: zcorpan: so about the validator behavior for text/html documents with an HTML4 or XHTML1, I would like to flip the default behavior such that we no longer do doctype sniffing and validate them against the HTML4 or XHTML1 schema but instead just validate them as HTML5 (i.e., as html5.validator.nu does) |
| 12:02 | <hsivonen> | MikeSmith: WFM |
| 12:06 | <MikeSmith> | hsivonen: Ok so my next question would be, as far as the UI, I don't think we need an option for "Do doctype sniffing for text/html" (or however it might be worded). But if you think we need one I can add it.a |
| 12:12 | <hsivonen> | MikeSmith: you mean getting rid of Preset: None and making Preset: default to HTML5? |
| 12:19 | <zcorpan> | hsivonen: not at hand, so possibly i'm making it up, but i could try to dig a bit |
| 12:22 | <MikeSmith> | hsivonen: no I just mean not adding any new option in the UI to let users revert to the old (currently existing) doctype-sniffing behavior (after we remove it) |
| 12:23 | <MikeSmith> | hsivonen: so users would lose the option to even opt into the doctype sniffing if they wanted it |
| 12:27 | <MikeSmith> | darobin: the studios should put Foliot on retainer |
| 12:28 | <darobin> | MikeSmith: have you seen Promised Land (that flick about fracking with Matt Damon)? |
| 12:28 | <darobin> | because I reckon the studios might just have Fred Andrews on retainer |
| 12:31 | <MikeSmith> | I think it's the otehr way around, that the EFF is paying Foliot to make the pro-EME argument look as absurd as possible. Kind of like, Man, If this is guy is p |
| 12:31 | <MikeSmith> | *if this guys is for it, it must really be a bad idea |
| 12:34 | <MikeSmith> | and as far as http://wiki.whatwg.org/wiki/Internet_Encrypted_Media_Extensions, is it crazy or completely wrong? |
| 12:34 | <MikeSmith> | I'm asking |
| 12:34 | <MikeSmith> | I mean I looked through it and on the face of it at least nothing there seems whacko |
| 12:36 | <MikeSmith> | I assume it's in the spirit of being a proposal in response to the rhetoric about "We can't discuss alternatives to EME unless we have actual proposals" |
| 13:06 | <zcorpan> | hsivonen: i only find http://lists.w3.org/Archives/Public/public-html/2009Mar/0581.html (see the end of it) |
| 13:07 | <zcorpan> | hsivonen: it was brought to my attention that svg2 also has meshGradient |
| 14:52 | <hsivonen> | MikeSmith: seems fine not to be able to opt into doctype sniffing |
| 14:53 | <MikeSmith> | hsivonen: ok cool |
| 14:55 | <MikeSmith> | hsivonen: the one case I can think of it breaking is if somebody's using the Web service API |
| 14:56 | <hsivonen> | yeah, but we can't freeze everything for that |
| 14:56 | <MikeSmith> | agree eyah |
| 14:57 | <MikeSmith> | but I guess we could add a request parameter |
| 14:57 | <MikeSmith> | that they'd need to specify if they wanted the old behavior |
| 14:57 | <MikeSmith> | that seems pretty low-cost |
| 14:58 | <hsivonen> | yes |
| 14:58 | <MikeSmith> | OK |
| 14:58 | <MikeSmith> | that's what I'll do then |
| 14:59 | MikeSmith | wanted to ask zcorpan if he had any concerns about this plan but I guess he's away right now |
| 15:09 | <zcorpan> | MikeSmith: what was the plan? |
| 15:11 | <zcorpan> | MikeSmith: no sniffing except for opt-in in web service api? |
| 15:14 | <zcorpan> | MikeSmith: is the plan to remove the option to sniff in the web service api later? if yes why not do it now? |
| 15:39 | <SimonSapin> | hsivonen: I picked 1024 from the HTML spec and Gecko code, and to not be tied too much to a set of supported encodings. Do you think it helps to reduce that number? How much? I think I used 100 bytes in tinycss2 and rust-cssparser |
| 15:39 | <SimonSapin> | zcorpan: what do you think of moving http://dev.w3.org/csswg/css-syntax/#environment-encoding-xml into CSSOM? |
| 15:39 | <SimonSapin> | into http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction actually |
| 15:40 | <zcorpan> | SimonSapin: wfm |
| 15:40 | <SimonSapin> | zcorpan: I’d do it, but I failed to make Anolis work for CSSOM :) |
| 15:41 | <zcorpan> | SimonSapin: i'll get around to it |
| 15:41 | <Ms2ger> | Does cssom still use the... interesting preprocessor? |
| 15:41 | <TabAtkins> | Yes. |
| 15:42 | <TabAtkins> | So far. |
| 15:42 | <TabAtkins> | zcorpan has said he wants to switch to Bikeshed. I think I just need to offer more forcefully to migrate him myself. |
| 16:12 | <jgraham> | Is CSS Serialization for getComputedStyle actualy defined now? |
| 16:13 | <annevk-cloud> | zcorpan: it trims whitespace cause that is what is needed in a ton of contexts |
| 16:13 | <annevk-cloud> | I can see an argument for not doing it there though, had not really considered that |
| 16:42 | <astearns> | jgraham: AFAICT no, at least not for interesting cases like multi-component values with optional parts |
| 16:43 | <SimonSapin> | browsers apparently do trim whitespace in @charset |
| 16:50 | <jgraham> | I don't really care about interesting edge cases |
| 16:51 | <jgraham> | I care very specifically about whether https://critic.hoppipolla.co.uk/585e8a45?review=447 is valid |
| 16:51 | <jgraham> | (actually I *do* care about those edge cases) |
| 16:51 | <jgraham> | (but not so much right now) |
| 16:51 | <jgraham> | (the failure to standardise this stuff is tragi-comic) |
| 16:54 | <Ms2ger> | Relative lengths: the <number> component serialized as per <number> followed by the unit in its canonical form as defined in its respective specification. |
| 17:03 | <jgraham> | OK, so that test is good then? |
| 17:08 | <TabAtkins> | Yeah. |
| 17:15 | <Ms2ger> | I dunnop |
| 17:15 | <Ms2ger> | dunno* |
| 17:21 | <gsnedders> | Huh. Understanding all possible transitions in the tree constructor is bloody hard. |
| 17:23 | <gsnedders> | The tree construction dispatcher makes it very non-obvious what's possible |
| 17:23 | <gsnedders> | As does resetting the insertion mode. |
| 17:29 | <dglazkov> | good morning, Whatwg! |
| 17:31 | <Ms2ger> | Hi dglazkov! |
| 17:38 | <jgraham> | dglazkov: Look I can beat Ms2ger! Lots of new PRs just waiting for your review! |
| 17:38 | <dglazkov> | jgraham: yay? |
| 17:38 | <jgraham> | https://critic.hoppipolla.co.uk/r/670 and https://critic.hoppipolla.co.uk/r/668 |
| 17:39 | <dglazkov> | today's chances looking slim. Gardening Blink. |
| 17:40 | <jgraham> | Did someone replae dglazkov with a magic eightball? |
| 17:42 | <Ms2ger> | Signs point to yes. |
| 17:46 | <dglazkov> | actually, I need to get hayato and morrita on to critic. They are the ones who should be looking at Shadow DOM and Imports tests, respectively. |
| 17:46 | <dglazkov> | and dominicc at Custom Elements |
| 17:46 | dglazkov | delegates |
| 17:48 | <jgraham> | dglazkov: Replacing yourself with three people sounds like a win |
| 17:49 | <jgraham> | Especially if they join IRC so we can nag them too ;) |
| 17:51 | <Ms2ger> | Nagging sounds good |
| 18:04 | <annevk> | heycam: you around? |
| 18:04 | <heycam> | annevk, yes |
| 18:04 | <annevk> | heycam: http://xhr.spec.whatwg.org/#interface-formdata |
| 18:04 | <annevk> | heycam: [Constructor(optional HTMLFormElement form)] |
| 18:05 | <annevk> | heycam: are you going to define what happens when HTMLFormElement is not part of the global? |
| 18:05 | <heycam> | annevk, for now, probably not; the conversion rules will just never consider any object passed in to be a value of the right type |
| 18:05 | <heycam> | since you can't get at one |
| 18:06 | <heycam> | look at all those [EnsureUTF16]s |
| 18:06 | <annevk> | heycam: except if you pass undefined since that'll mean missing? |
| 18:06 | <heycam> | annevk, sure |
| 18:06 | <annevk> | heycam: yeah you need to come up with a consistent story for EnsureUTF16 and ByteString :-) |
| 18:06 | <heycam> | I know |
| 18:06 | <annevk> | heycam: okay, sounds good |
| 18:11 | <MikeSmith> | grr zcorpan away again |
| 18:13 | <Ms2ger> | That damn zcorpan, being at home with his family |
| 18:21 | <bterlson> | j #temporaldeadzone |
| 18:34 | <annevk> | heycam: are callbacks and enmums automatically available everywhere? |
| 18:34 | <heycam> | annevk, yes |
| 18:34 | <heycam> | annevk, you mean in all globals? or all specs? |
| 18:34 | <heycam> | either way, yes |
| 18:34 | <annevk> | yes |
| 18:36 | <Hixie> | enums aren't detectable in a global, right? |
| 18:36 | <Hixie> | i mean, they're just strings |
| 18:36 | <heycam> | right |
| 19:11 | <annevk> | MikeSmith: https://twitter.com/sideshowbarker/status/428240986465005568 <3 |
| 21:13 | marcosc | wonders how MikeSmith just gets better looking year after year .... |
| 21:14 | <marcosc> | must be the drugs, booze, and party animal lifestyle. |
| 21:40 | <Hixie> | any IE-capable users around? |
| 21:40 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2780 |
| 22:04 | <annevk> | So I think I just learned custom elements invented nanotasks |
| 22:06 | <TabAtkins> | ?!? |
| 22:06 | <annevk> | http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks |
| 22:06 | <annevk> | "When transitioning back from the user agent code to script, pop the element queue from the processing stack and invoke callbacks in that queue." |
| 22:07 | <annevk> | That should really be discussed in the context of TC39 I think |
| 22:07 | <Hixie> | what does that even mean, exactly? |
| 22:07 | <Hixie> | to do something similar in HTML we needed a bunch of WebIDL hooks |
| 22:07 | <annevk> | I think it means that x.do(); /* nanotask */ x.doElse(); |
| 22:08 | <Hixie> | setTimeout(window.open, 0, ...); does this happen when the timeout fires at all? |
| 22:09 | <annevk> | Well that is a different problem I think |
| 22:13 | <Hixie> | ah |
| 22:14 | <Hixie> | how about dispatchEvent(), does it "transition back from user agent code to script"? or vice versa? or both? |
| 22:24 | <Domenic_> | Hmm those nanotasks look bad |
| 22:35 | <TabAtkins> | That's not what it means. It's meant to be referring to microtask checkpoints. |
| 22:35 | <TabAtkins> | I'm almost certain; if I'm wrong, we shoudl complain harder. |
| 22:37 | <annevk> | I'm going to raise it on the list in a bit |
| 22:39 | gsnedders | wonders if we have interop on what <script>document.write("uD800uDC80");</script> does. |
| 22:39 | <gsnedders> | Because having that actually insert U+10080 would be so much nicer. |
| 22:44 | <Hixie> | so... why did we not make </caption> optional? |
| 23:03 | <dglazkov> | these are neither nanotasks, nor microtask checkpoints |
| 23:03 | <dglazkov> | they are simply an auto-release pool-like barrier between UA code and user code |
| 23:04 | <annevk> | dglazkov: given mutation events you'll have to define that a lot better |
| 23:04 | <Hixie> | so if you call an array's "sort" method with a user-code function that manipulates the DOM, do they run between each call to the sort function? |
| 23:04 | <Hixie> | sorter function, rather? |
| 23:05 | <dglazkov> | theoretically yes, but in practice no, because sort function itself is incapable of introducing the relevant DOM changes |
| 23:06 | <Hixie> | why not? |
| 23:06 | <dglazkov> | how? :) |
| 23:06 | <Hixie> | the sort function can do anything, even opening new browsing contexts and creating new documents |
| 23:06 | <Hixie> | it's just user code |
| 23:06 | <Hixie> | array.sort(function (a, b) { ...do whatever you want... }); |
| 23:06 | <dglazkov> | by sort function I meant Array.sort |
| 23:07 | <annevk> | Hixie did too |
| 23:07 | <dglazkov> | Array.sort in itself does not do any dom changes. |
| 23:07 | <annevk> | oh I see |
| 23:07 | <Hixie> | even if you apply it to an Element? it's a generic function, no? |
| 23:07 | <annevk> | dglazkov: so what you're saying is that you are monkey patching methods and properties that do changes to the DOM |
| 23:07 | <annevk> | dglazkov: to process your nanotasks or whatever you want to call them |
| 23:07 | <annevk> | dglazkov: without defining that in detail |
| 23:08 | <dglazkov> | in practice, there are actually only a few methods need that. See CustomElementCallbacks tag on the Blink idls: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.idl&q=Document.idl&sq=package:chromium&type=cs |
| 23:08 | <Hixie> | surely if you apply JS Array.sort() to a proxy object whose user-specified internal methods ([[Get]], etc) manipulate the DOM... |
| 23:09 | <gsnedders> | You don't even need proxies. ES5's getters/setters are enough even with the default comparator |
| 23:10 | <dglazkov> | Hixie: it's not at all about what the proxy object does. It's what the Array.sort itself does internally. If it's applied to another object, that object will have the barriers around the things that trigger changes. |
| 23:10 | <Hixie> | ah |
| 23:10 | <Hixie> | sounds like it'd be better to define it in terms of those barriers then |
| 23:10 | <Hixie> | rather than all user->ua code transitions |
| 23:10 | <dglazkov> | I was actually thinking of moving this barrier thing into a separate abstraction. It's very primitively defined in the custom elements spec |
| 23:11 | <dglazkov> | yup |
| 23:11 | <annevk> | Yeah, you want to just define this in the relevant methods I think |
| 23:11 | <dglazkov> | because all rendering engines actually have these types of things. |
| 23:11 | <annevk> | We do have it, but not exposed to web content |
| 23:11 | <annevk> | And the way it works in Gecko is similar to mutation events, which we just tried to remove |
| 23:12 | <dglazkov> | right. And I avoided it as an exposed API in custom elements |
| 23:12 | <annevk> | Well these callbacks are certainly exposed |
| 23:12 | <dglazkov> | annevk: it's different from mutation events, because the callbacks are actually only invoked at a safe point |
| 23:12 | <dglazkov> | that's the whole point of the barrier |
| 23:12 | <annevk> | Well, you're saying they are the same as what engines have, but you saying that means they are not |
| 23:13 | <annevk> | E.g. appendChild(node) will remove node from its parent first and then run adopt; we'd run code after the removal |
| 23:13 | <annevk> | That would be problematic |
| 23:13 | <dglazkov> | we |
| 23:13 | <annevk> | I meant Gecko there |
| 23:13 | <dglazkov> | will run the code just before appendChild method returns |
| 23:13 | <dglazkov> | no problems :) |
| 23:14 | <annevk> | Well the way this is defined is problems imo |
| 23:14 | <annevk> | We should just patch the methods this affects to make it way more transparent |
| 23:14 | <dglazkov> | annevk: that's not necessarily the best strategy. Every time you add a new DOM API, you'd have to patch up the spec. |
| 23:15 | <dglazkov> | annevk: the easiest thing to do is to say -- do this for all UA code and leave UA vendors opportunities to optimize when it's certain that the callbacks won't be queued. |
| 23:15 | <annevk> | Not if we move to a world where more is self-hosted |
| 23:15 | <annevk> | And the lines become blurry |
| 23:16 | <dglazkov> | sure. Then we will need this abstraction as a separate API |
| 23:16 | <dglazkov> | it's not like the current solution closes this path |
| 23:16 | <annevk> | Also having to know that a callback can run at the end of a method and not having it defined there is a pretty bad way to write a specification imo |
| 23:17 | <annevk> | You have effectively changed a large set of the default library methods, without telling the people who define those methods |
| 23:17 | <dglazkov> | how so? |
| 23:18 | <dglazkov> | what's a default library? |
| 23:20 | <dglazkov> | as I said before, the alternative is to create a strict dependency on all possible things that could cause DOM changes. I don't think that's much better either. |
| 23:20 | <Hixie> | why is that not better? |
| 23:20 | <Hixie> | i mean, ideally, this would just be in the DOM spec, no? presumably that's what we're going to do eventually |
| 23:21 | <dglazkov> | because that's not an easily bound set |
| 23:21 | <dglazkov> | what about CSSOM, Editing, Selection, etc? |
| 23:21 | <Hixie> | what about them? |
| 23:21 | <Hixie> | wouldn't they be defined in terms of the DOM algorithms? |
| 23:21 | <dglazkov> | why would that matter? |
| 23:22 | <Hixie> | well if the logic is in the DOM algorithms, that would just trigger them, i guess |
| 23:22 | <Hixie> | i don't really understand what we're trying to do here, so my advice may not be useful |
| 23:22 | <dglazkov> | what matters is that anytime anyone decides to invent a supplemental IDL, I'd have to be on the lookout for that spec and evaluate whether their methods need to be explicitly mentioned in the spec |
| 23:23 | <Hixie> | well, they have to be on the lookout for whether they need to worry about the DOM spec, rather, but yeah |
| 23:23 | <Hixie> | we all have to make sure we're aware of each other's work |
| 23:24 | <dglazkov> | Hixie: there maybe something to that. The spec has a well-defined set of DOM manipulations that causes callbacks to enqueue |
| 23:24 | <Hixie> | all DOM manipulations go through the DOM spec |
| 23:25 | <dglazkov> | yup |
| 23:25 | <dglazkov> | the only issue is when the callbacks are invoked. |
| 23:25 | <Hixie> | so if you monkeypatch the DOM spec, any other new spec that does DOM manipulations is supported for free, right? |
| 23:25 | <Hixie> | wait, you're calling user code here? |
| 23:25 | <dglazkov> | the queueing, right. I already did that |
| 23:25 | <Hixie> | in the middle of other user code? |
| 23:25 | <dglazkov> | no |
| 23:25 | <annevk> | dglazkov: you need to be on the lookout anyway, because you implemented this with an IDL extension |
| 23:26 | <Hixie> | i guess i don't understand the issue here |
| 23:26 | <dglazkov> | me neither :) |
| 23:26 | <annevk> | dglazkov: it's better if we centralize that lookout, than do it on a per engine level |
| 23:27 | <annevk> | Hixie: the idea is to call user code just before you return from certain method calls |
| 23:27 | <annevk> | dglazkov: bz pointed out that you pass the mutation events problem on to JS implemented libraries |
| 23:27 | <Hixie> | annevk: dglazkov just said that it wasn't that |
| 23:28 | <dglazkov> | annevk: I guess I want to understand what is the "mutation events problem", then. It doesn't fit my understanding of what I thought it was. |
| 23:28 | <annevk> | dglazkov: e.g. if you appendChild() a node and then its leftView callback calls remove child and then its enteredView callback will be confused |
| 23:28 | <dglazkov> | annevk: no, it's not |
| 23:28 | <dglazkov> | please read the spec |
| 23:29 | <annevk> | dglazkov: from the perspective of the JS library |
| 23:29 | <dglazkov> | the whole notion of the queues is to ensure the consistent sequence of callbacks |
| 23:29 | <annevk> | dglazkov: not the browser |
| 23:29 | <dglazkov> | annevk: yes, that's exactly what I am talking about, too |
| 23:29 | <Hixie> | why aren't we just using the mutation observers here? |
| 23:29 | <Hixie> | it sounds rather similar... |
| 23:30 | <dglazkov> | mutation observers are too late |
| 23:30 | <Hixie> | too late for what? |
| 23:30 | <dglazkov> | for developers: var foobar= document.createElement("foo-bar"); foobar.doStuff(); |
| 23:31 | <dglazkov> | if you use mutation observers, doStuff will be operating on an uninitialized object. |
| 23:31 | <dglazkov> | because createdCallback will be called at a microtask checkpoint |
| 23:31 | <Hixie> | sure, when you _create_ an element that's bound you need to run its constructor |
| 23:32 | <dglazkov> | annevk: I am happy to explain the element/callback queues and how they help the JS developer keep a consistent view of the world. |
| 23:33 | <dglazkov> | annevk: the key here is that as long as JS developer listens to callbacks, their sequence is always correct. There is no inconsistent state. |
| 23:33 | <Hixie> | well an element is only created once, right? |
| 23:33 | <Hixie> | why is there a queue? |
| 23:33 | <Hixie> | surely it should just be synchronous with element creation |
| 23:34 | <annevk> | dglazkov: so I have a custom element X that has all the lifecycle callbacks |
| 23:35 | <dglazkov> | Hixie: expand this example to when I innerHTML "<foo-bar>" and then try to query for it with querySelector |
| 23:35 | <Hixie> | dglazkov: how is that different? |
| 23:35 | <annevk> | dglazkov: I have two globals each with a document (A, B), X is part of B |
| 23:35 | <annevk> | dglazkov: I then do appendChild(X) in A |
| 23:35 | <dglazkov> | what's two globals? can you explain a bit? |
| 23:36 | <annevk> | dglazkov: A is a document and B is <iframe>.contentDocument nested in A |
| 23:36 | <dglazkov> | okay |
| 23:37 | <annevk> | dglazkov: I was assuming the callbacks leftView and enteredView would invoke at that point |
| 23:38 | <dglazkov> | it depends on where A is registered |
| 23:38 | <dglazkov> | where X is registered, sorry :) |
| 23:38 | <annevk> | In B |
| 23:40 | <annevk> | If it's simpler we could first consider A and B being in the same global |
| 23:41 | <dglazkov> | sure, let's do it |
| 23:43 | <annevk> | Okay, I figured you would take it from here, but am I correct that leftView and enteredView would be called before appendChild(X) returns? |
| 23:43 | <annevk> | In that order? |
| 23:43 | annevk | has to go for a bit in 10 minutes unfortunately |
| 23:44 | <annevk> | And then the question is if the leftView callback removes X again, how will enteredView not be confused? Will it be removed from the callback queue? |
| 23:44 | <annevk> | dglazkov: ^ |
| 23:46 | <dglazkov> | it won't be confused, because there is an element queue, which drains all callbacks per element at the time of invocation. This ensures a consistent sequence of callbacks. |
| 23:48 | <dglazkov> | so yes, just before appendChild(X) returns, X will see a sequence of callbacks. If a callback code itself enqueues another callback, that callback goes to the end of the callback queue for this element |
| 23:48 | <dglazkov> | if you'd like, we can VC/Skype/whatevs |
| 23:49 | Hixie | encourages the use of archived communication methods so that other people can learn from the discussion |
| 23:51 | <dglazkov> | we can do hangout on air and post a youtube video of me struggling with a felt marker |
| 23:52 | <gsnedders> | +1 for this if it involves making fun of dglazkov |
| 23:54 | <Hixie> | well a hangout on air isn't as convenient as an irc conversation, but it's a step up from a private vc :-) |
| 23:55 | <annevk> | dglazkov: I'll get back to you on this I guess |
| 23:55 | <annevk> | dglazkov: I have to do something now |
| 23:55 | <dglazkov> | annevk: no worries. I have to run, too |